How to Protect Your Website from Hacking: 2026 Guide

Website Security

Last updated: July 2, 2026

A website does not need to be famous, controversial, or profitable to attract attackers. Automated bots continuously scan the public internet for outdated plugins, exposed administration panels, weak passwords, leaked API keys, vulnerable upload forms, misconfigured cloud storage, and servers that missed a security update.

The uncomfortable truth is that a hacked website may continue looking completely normal. Visitors can see the usual homepage while hidden code redirects search-engine users, creates spam pages, steals checkout details, sends phishing emails, mines cryptocurrency, adds secret administrator accounts, or gives the attacker a way back after the visible malware is removed.

This guide explains how to protect a website in 2026 using layered security. It covers domain and DNS protection, hosting, WordPress hardening, administrator accounts, passkeys and multi-factor authentication, software updates, third-party dependencies, web application firewalls, HTTPS, security headers, databases, custom code, file uploads, backups, monitoring, incident response, and recovery.

Important: No honest security guide can promise that a website will become “unhackable.” The real goal is to reduce the chance of compromise, limit the damage if one control fails, detect suspicious activity quickly, and restore the site without paying an attacker.

The 15-Minute Website Security Plan

If the website is live and you are not sure where to begin, complete these actions first:

  1. Turn on multi-factor authentication for the domain registrar, DNS provider, hosting account, WordPress administrators, email, source-code repository, and cloud services.
  2. Change reused administrator passwords to unique passwords stored in a reputable password manager. Use passkeys or hardware security keys where available.
  3. Update the website stack: CMS core, plugins, themes, extensions, server packages, runtime, frameworks, libraries, and control-panel software.
  4. Delete software you do not use. Deactivated WordPress plugins, abandoned themes, old staging copies, test scripts, and forgotten subdomains remain attack surface.
  5. Check every administrator account and remove unknown, duplicate, dormant, former employee, and former agency users.
  6. Confirm that automated backups are working and that at least one recent copy is stored away from the live hosting account.
  7. Enable a web application firewall and rate limiting through a reputable hosting provider, reverse proxy, CDN, or managed security service.
  8. Review the hosting file manager for unexpected PHP files, recently modified core files, unknown scheduled tasks, and writable directories that should not be writable.
  9. Check Search Console and external monitoring for malware, phishing, strange indexed pages, sudden traffic changes, and browser warnings.
  10. Write down who to contact if the site fails: hosting support, developer, payment provider, domain registrar, security specialist, and business decision-maker.

These actions do not finish the job, but they close several of the most common doors before you move into deeper hardening.

What Complete Website Security Actually Means

Website security is not one plugin, one firewall, or one perfect password. It is a system with four jobs:

Security job What it means Example
Prevent Make compromise more difficult MFA, updates, secure code, least privilege, WAF rules
Contain Limit what one compromised account or component can reach Separate databases, restricted file permissions, isolated sites
Detect Notice suspicious activity before the damage grows Login alerts, file-integrity monitoring, log analysis, payment alerts
Recover Restore clean service and close the original entry point Tested off-site backups, incident plan, credential rotation

The official WordPress hardening documentation describes security as risk reduction rather than perfect protection. That is the right mindset for every platform.

A site with excellent prevention but no monitoring can stay infected for months. A site with excellent backups but weak administrator security may be restored and hacked again the same day. Complete protection means the layers support one another.

1. Know What You Own Before You Try to Protect It

You cannot protect an asset you have forgotten. Create a simple website inventory containing:

  • Primary domains, parked domains, and country-code domains.
  • DNS provider and registrar.
  • Hosting accounts, servers, containers, and cloud projects.
  • Production, staging, testing, and development websites.
  • Subdomains, APIs, admin panels, webmail, databases, and file-transfer services.
  • CMS, framework, language runtime, web server, database, and operating system.
  • WordPress plugins, themes, must-use plugins, and custom snippets.
  • JavaScript, PHP, Python, Node.js, Composer, npm, or other dependencies.
  • CDN, WAF, analytics, tag manager, advertising, forms, chat, and payment integrations.
  • Administrator accounts and the people responsible for them.
  • API keys, webhooks, SSH keys, deployment credentials, and backup locations.

Include renewal dates, owners, and recovery contacts. A forgotten subdomain running an old CMS can compromise the reputation of the main domain even if the primary site is fully patched.

Mark each component as:

  • Required and maintained.
  • Required but needs an update or replacement.
  • Unknown purpose.
  • Safe to remove.

Reducing attack surface is one of the most reliable improvements available. Every deleted plugin, closed port, removed user, retired test site, and revoked API key is one less thing that must remain perfect forever.

2. Protect the Domain Name and DNS Account

Website owners often focus on WordPress while leaving the domain registrar protected by an old password and no MFA. That is backwards. Someone who controls the domain can redirect visitors and email, issue certificates, replace DNS records, or move the domain away from the legitimate owner without touching the web server.

Secure the registrar and DNS provider

  • Use unique passwords stored in a password manager.
  • Enable phishing-resistant MFA, a passkey, or a hardware security key when supported.
  • Use an email address that is itself strongly protected and not dependent on the same domain being recovered.
  • Enable registrar lock or clientTransferProhibited.
  • For valuable domains, ask whether registry lock is available.
  • Turn on notifications for logins, DNS edits, contact changes, nameserver changes, and transfer requests.
  • Review recovery contacts and remove old employees or agencies.
  • Keep proof of ownership, invoices, registration records, and account identifiers offline.

ICANN explains the purpose of registrar locking, while the UK National Cyber Security Centre provides broader guidance for managing public domain names securely.

Use DNSSEC where it is supported and correctly maintained

DNSSEC adds cryptographic validation to DNS responses. It can help prevent certain forms of DNS tampering, but it must be configured correctly at both the DNS provider and registrar. A broken delegation can make the domain unreachable, so enable it only when the provider supports the process clearly.

DNSSEC does not replace registrar security, HTTPS, or server hardening. It protects a different layer.

Do not expose the origin server unnecessarily

When a reverse proxy or CDN protects the site, restrict the origin so it accepts web traffic only from the proxy’s documented IP ranges where practical. Otherwise, attackers may bypass the WAF and send requests directly to the server IP.

Also review old DNS records. A forgotten subdomain pointing to an abandoned cloud service can create a subdomain-takeover risk.

3. Choose and Harden the Hosting Environment

A cheap hosting plan can be perfectly adequate for a small site, but the provider must maintain the infrastructure responsibly. Ask what the host handles and what remains your responsibility.

Look for:

  • Supported operating systems, database versions, PHP or runtime versions, and web-server software.
  • Automatic security patching and a clear end-of-life policy.
  • Account-level isolation on shared hosting.
  • Malware scanning and outbound-spam detection.
  • DDoS protection, rate limiting, and WAF options.
  • Encrypted SFTP or SSH rather than plain FTP.
  • Automated backups with off-site or immutable options.
  • Access logs, error logs, audit logs, and retention periods.
  • Responsive incident support and a clear abuse process.

Close services you do not use

On a VPS or dedicated server:

  • Allow only required inbound ports.
  • Restrict SSH by firewall, VPN, allowlist, or identity-aware access where practical.
  • Disable password-based SSH after verified key-based access is working.
  • Disable direct root login and use a separate administrative account with controlled privilege escalation.
  • Remove unused databases, interpreters, control panels, and network services.
  • Keep the operating system and packages within supported versions.

On managed or shared hosting, you may not control the server firewall. You still control the application, users, SFTP accounts, databases, backups, and software installed inside the account.

Separate unrelated websites

Do not place every client project, experiment, and profitable site under one unrestricted hosting user if isolation options are available. One vulnerable plugin on an abandoned site can give an attacker access to sibling sites stored under the same account.

Use separate hosting accounts, containers, virtual hosts, system users, or cloud projects for websites with different risk levels. Isolation turns one compromise into one incident instead of ten.

4. Secure Every Administrator and Hosting Login

The strongest application code cannot compensate for a stolen administrator session. Protect:

  • Domain registrar.
  • DNS and CDN.
  • Hosting control panel.
  • WordPress or CMS administrators.
  • Webmail and business email.
  • SSH, SFTP, database, and cloud console.
  • GitHub, GitLab, Bitbucket, or another source repository.
  • Backup service.
  • Payment gateway and advertising accounts.

Prefer passkeys or phishing-resistant MFA

An authenticator application is substantially better than password-only access. A passkey or hardware security key is stronger against conventional phishing because the authentication is tied to the legitimate service.

Use SMS when it is the only available second factor, but protect the mobile-provider account and replace SMS with a stronger option where practical.

Use long, unique passwords—do not rotate them pointlessly

The old recommendation to force a password change every eight weeks can produce predictable variations and password reuse. Current NIST authentication guidance says passwords should not be changed periodically without a reason.

Change a password when:

  • It was reused.
  • It was shared.
  • It appeared in a breach.
  • It was entered into a suspicious page.
  • The device or account may be compromised.
  • A person who knew it no longer requires access.

Store passwords in a reputable password manager. Do not keep them in email, chat, project notes, browser screenshots, or a spreadsheet shared with the whole team.

Review sessions, not only passwords

Changing a password may not remove every existing session, API token, app password, SSH key, or trusted device. After suspected compromise:

  • Log out other sessions.
  • Revoke remembered devices.
  • Rotate API tokens and app passwords.
  • Remove unknown passkeys and security keys.
  • Review OAuth applications.

5. Update Core Software, Plugins, Themes, and Dependencies

Public vulnerability details often appear soon after a patch is released. Attackers can compare the fixed version with the old version, build an exploit, and scan the internet for websites that delayed updating.

Update:

  • CMS core.
  • Plugins, modules, extensions, and themes.
  • PHP, Python, Node.js, Java, .NET, Ruby, and other runtimes.
  • Frameworks and libraries.
  • Web server, database, operating system, and control panel.
  • Composer, npm, pip, container, and system packages.
  • CDN, tag-manager, analytics, and embedded third-party scripts when you control the version.

Use a risk-based update process

Not every update needs the same response time. Prioritize:

  1. Vulnerabilities known to be actively exploited.
  2. Unauthenticated remote-code execution.
  3. Authentication bypass and administrator takeover.
  4. Arbitrary file upload or file deletion.
  5. SQL injection and sensitive-data exposure.
  6. Components exposed directly to the internet.

The CISA Known Exploited Vulnerabilities Catalog is useful for prioritizing vulnerabilities that attackers are using in the real world.

Test important updates without turning “testing” into permanent delay

For a business-critical site:

  • Create a current backup.
  • Test major changes on a protected staging copy.
  • Review release notes and compatibility warnings.
  • Deploy promptly.
  • Test login, forms, checkout, email, caching, and scheduled tasks.
  • Keep a documented rollback route.

A staging workflow should reduce update risk, not justify leaving a critical vulnerability open for months.

6. Treat Plugins, Themes, Packages, and Build Tools as a Supply Chain

Modern websites are assembled from code written by many organizations. The 2025 OWASP Top 10 explicitly recognizes software supply-chain failures as a major application-security category.

A trusted-looking plugin can become dangerous if:

  • The developer account is compromised.
  • The project is sold to an untrustworthy owner.
  • An update server is breached.
  • A package name is impersonated.
  • A dependency introduces vulnerable code.
  • A build pipeline or signing key is stolen.

Read the OWASP Software Supply Chain Security Cheat Sheet for deeper technical guidance.

Reduce supply-chain risk

  • Install software only from the official repository or established vendor.
  • Never install nulled, cracked, pirated, or “premium unlocked” plugins and themes.
  • Check recent update history, support activity, ownership, and compatibility.
  • Remove abandoned components instead of waiting indefinitely for a patch.
  • Pin dependency versions and commit lockfiles for custom applications.
  • Use automated dependency alerts and vulnerability scanning.
  • Review unexpected changes in package ownership or permissions.
  • Protect source repositories and CI/CD with MFA and branch protection.
  • Generate or maintain a dependency inventory or software bill of materials for important applications.

Do not install three overlapping security plugins, two abandoned optimization plugins, and an unknown theme framework “just in case.” More code means more updates, permissions, conflicts, and opportunities for failure.

7. Harden WordPress Without Relying on Security Myths

WordPress can be operated securely, but its popularity makes vulnerable plugins, weak administrator accounts, and abandoned installations attractive targets.

Use the official WordPress hardening baseline

The WordPress Hardening guide covers updates, permissions, databases, administration, plugins, backups, logging, and monitoring.

For most WordPress sites:

  • Keep WordPress core, plugins, and themes updated.
  • Delete unused plugins and themes instead of merely deactivating them.
  • Use only trusted sources.
  • Give administrator access only to people who need it.
  • Enable MFA for every administrator.
  • Use SFTP or SSH instead of plain FTP.
  • Use strict file ownership and permissions appropriate to the host.
  • Keep the site on a supported PHP version.
  • Protect the hosting account and database separately.

Disable dashboard file editing

If administrators do not need to edit PHP through the WordPress dashboard, add this to wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

This does not stop every compromise, but it removes a convenient code-execution tool from an attacker who gains dashboard access.

Protect wp-config.php and sensitive files

Ensure the server does not serve:

  • wp-config.php
  • Backup archives.
  • Database exports.
  • .env files.
  • Git metadata.
  • Server logs.
  • Composer authentication files.

Store secrets outside the public web root where the hosting environment supports it, and use restrictive permissions.

Use appropriate WordPress roles

An editor does not need administrator rights to publish articles. A support worker does not need permission to install plugins. A temporary developer should not retain an account six months after the job ends.

Use Administrator, Editor, Author, Contributor, Subscriber, and custom roles according to real job requirements.

Be careful with XML-RPC, REST API, and login changes

Do not disable features blindly because a checklist says they are “dangerous.”

  • XML-RPC may be needed by certain mobile, Jetpack, publishing, or integration workflows. Restrict or disable it when unused, but test first.
  • The WordPress REST API supports core functionality. Sensitive endpoints must enforce authentication and authorization rather than relying on obscurity.
  • Changing the login URL may reduce bot noise, but it is not a substitute for MFA, rate limiting, updates, and strong credentials.

Do not overvalue the database prefix

Changing wp_ may disrupt simplistic automated assumptions, but it does not repair a vulnerable SQL query or compromised administrator. Treat it as minor obscurity, not a main security control.

Use one carefully selected security stack

A WordPress security plugin can add login protection, file monitoring, malware scanning, audit logs, and firewall rules. A cloud WAF can block malicious traffic before PHP and WordPress load.

Choose tools that:

  • Are actively maintained.
  • Explain what each setting does.
  • Do not conflict with the host or another security plugin.
  • Send alerts to a monitored address.
  • Allow recovery without locking out the owner.

A plugin is a control inside WordPress. It cannot protect the registrar, hosting account, infected laptop, stolen email session, or compromised DNS provider.

8. Put a WAF, CDN, Rate Limits, and DDoS Protection in Front of the Site

A web application firewall examines requests and can block common exploit patterns, abusive bots, brute-force traffic, malicious payloads, and known attack sources.

A reverse-proxy WAF sits before the origin server. This is valuable because rejected traffic may never reach WordPress, PHP, the application, or the database.

Configure the WAF around the actual site

Useful controls include:

  • Managed rules for common web vulnerabilities.
  • Rate limits for login, password reset, registration, search, API, and form endpoints.
  • Bot management or challenges for suspicious automation.
  • Country or network restrictions only when they match the real audience and risk.
  • Protection for XML-RPC and other commonly abused endpoints when applicable.
  • Upload-size and request-body limits.
  • DDoS protection and caching for public content.

Do not switch every aggressive rule to “block” without testing. A badly configured WAF can stop checkout, API callbacks, payment webhooks, accessibility tools, search crawlers, or legitimate administrators.

Start new complex rules in log or simulate mode, review events, then enforce them.

Protect the origin

If the site uses a proxy:

  • Restrict direct web access to the proxy’s networks where possible.
  • Do not publish the origin IP unnecessarily.
  • Verify the real visitor IP through the provider’s trusted mechanism.
  • Prevent attackers from forging proxy headers.

A WAF reduces exposure; it does not excuse vulnerable code or abandoned plugins.

9. Use HTTPS Correctly—But Do Not Mistake It for Full Security

HTTPS encrypts traffic between the visitor and the website. It helps protect passwords, forms, cookies, and content from interception or modification in transit.

A free certificate from Let’s Encrypt is suitable for many websites. Most managed hosts and control panels can issue and renew certificates automatically.

HTTPS does not prove that the site itself is safe

A valid certificate does not prove that:

  • The website is not malicious.
  • The application has no vulnerabilities.
  • The server is free from malware.
  • The owner is trustworthy.
  • Customer data is encrypted in the database.

Attackers can obtain certificates for domains they control. HTTPS protects the connection, not the intentions or code behind it.

Deploy HTTPS correctly

  • Redirect all HTTP traffic to HTTPS.
  • Remove mixed-content resources.
  • Automate certificate renewal.
  • Monitor expiration and failed renewals.
  • Use secure cookies.
  • Consider HSTS only after every required subdomain works reliably over HTTPS.
  • Disable obsolete TLS protocols and weak cipher configurations through the hosting provider.

Test certificate and TLS configuration after changes. An expired certificate or overaggressive HSTS policy can make a legitimate site inaccessible.

10. Add Modern Browser Security Headers

Security headers tell the browser how content may load and interact. They can reduce the impact of XSS, clickjacking, MIME confusion, data leakage, and insecure transport.

The OWASP HTTP Security Response Headers Cheat Sheet explains current recommendations.

Important headers include:

  • Content-Security-Policy: Restricts scripts, styles, frames, images, connections, and other resources.
  • Strict-Transport-Security: Tells browsers to use HTTPS for a defined period.
  • X-Content-Type-Options: nosniff: Reduces MIME-type confusion.
  • Referrer-Policy: Limits information sent in the referrer header.
  • Permissions-Policy: Restricts browser features such as camera, microphone, and geolocation.
  • frame-ancestors in CSP: Controls who may frame the site and helps prevent clickjacking.
  • Secure, HttpOnly, and SameSite cookie attributes: Protect session cookies in different ways.

Deploy CSP gradually

A strict Content Security Policy can break analytics, ads, embedded videos, checkout, consent tools, and inline scripts.

Use:

  1. Content-Security-Policy-Report-Only.
  2. Report collection and review.
  3. Nonces or hashes for required scripts.
  4. A tested enforcement policy.

Do not create a policy filled with broad wildcards and unsafe-inline merely to earn a scanner grade. The policy must match the site’s real content and threat model.

Test the public site with the Mozilla HTTP Observatory, then review every recommendation rather than copying headers blindly.

11. Apply Least Privilege to Files, Databases, Cloud Services, and Staff

Least privilege means giving each account and process only the access required for its job.

Examples:

  • A content editor cannot install plugins.
  • The web application can access only its own database.
  • A backup service can write new backups but cannot silently delete every historical copy.
  • An image-processing worker cannot administer the server.
  • A support contractor cannot access billing or DNS.
  • A public upload directory cannot execute PHP or server-side scripts.

Use restrictive file permissions and ownership

On many Linux hosting environments, ordinary files commonly use 644 and directories 755, but the correct model depends on user ownership, the web-server process, deployment method, and host.

Avoid 777. World-writable permissions are rarely the correct fix for an upload or cache error.

The important questions are:

  • Which user owns the file?
  • Which process must read it?
  • Which process must write it?
  • Does it need execute permission?

Only designated content, cache, and upload directories should normally require application write access.

Restrict database access

  • Use a separate database user per site or application.
  • Do not use the database root account from the web application.
  • Bind the database to a private interface where possible.
  • Restrict remote database access by network and authentication.
  • Give the application only required privileges.
  • Encrypt sensitive backups and exports.

Some CMS updates require schema changes, so test restrictive database privilege models carefully.

12. Protect Passwords, API Keys, Tokens, and Other Secrets

Secrets include:

  • Database credentials.
  • API keys.
  • Payment and email-service tokens.
  • SSH private keys.
  • OAuth client secrets.
  • Webhook signing secrets.
  • Encryption keys.
  • Cloud-access credentials.

The OWASP Secrets Management Cheat Sheet recommends managing the full secret lifecycle: creation, access, rotation, revocation, expiration, and auditing.

Do not hardcode secrets into public code

Avoid placing secrets in:

  • JavaScript delivered to the browser.
  • Public Git repositories.
  • Theme or plugin files.
  • Images, comments, examples, and documentation.
  • Container images.
  • Logs and error messages.

Use environment variables, protected configuration, or a managed secret store appropriate to the platform.

If a secret enters a Git commit, deleting it from the latest file is not enough. Treat it as exposed: revoke or rotate it, then address the repository history according to the platform’s guidance.

Make rotation possible before an emergency

Document:

  • Where each secret is used.
  • Who can rotate it.
  • How to revoke it.
  • What service stops working after rotation.
  • How to test the replacement.

A secret that cannot be rotated without several hours of guesswork becomes a serious incident-response weakness.

13. Build Custom Code Around the OWASP Top 10:2025

For custom applications, use the OWASP Top 10:2025 as an awareness baseline. It covers:

  1. Broken access control.
  2. Security misconfiguration.
  3. Software supply-chain failures.
  4. Cryptographic failures.
  5. Injection.
  6. Insecure design.
  7. Authentication failures.
  8. Software or data integrity failures.
  9. Logging and alerting failures.
  10. Mishandling of exceptional conditions.

The list is not a complete development standard. Pair it with threat modelling, code review, secure framework defaults, dependency management, testing, and the OWASP Cheat Sheet Series.

Make security part of design—not a final plugin

Before development, ask:

  • What sensitive data will exist?
  • Who may read, change, export, or delete it?
  • What happens if a request is repeated, delayed, reordered, or partially fails?
  • Can one user change another user’s object ID?
  • Can a browser request an internal URL through the server?
  • What does the system do when a payment webhook is delivered twice?
  • What happens if an external API is unavailable?
  • Does the application fail closed or accidentally grant access?

Security bugs often live in workflow logic, not only in obviously dangerous code.

14. Enforce Access Control on Every Request

Hiding an admin button does not protect the underlying action. The server must verify authorization every time a user requests a page, record, file, API object, export, or administrative operation.

Check:

  • Is the user authenticated?
  • Does this user have the required role?
  • Does this record belong to this user or organization?
  • Is the action allowed in the current state?
  • Should this field be changeable by this role?

Do not trust object IDs

A URL such as:

/account/invoice/4812

must not return invoice 4812 merely because the user changed 4811 to 4812. The server must verify ownership or permission.

Apply the same check to:

  • Downloads.
  • Images and private documents.
  • API endpoints.
  • Exports.
  • Support tickets.
  • Orders and subscriptions.
  • Administrative AJAX requests.

Use deny-by-default policies. New endpoints should not become public because someone forgot to add an authorization rule.

15. Prevent SQL Injection and Other Injection Attacks

Injection occurs when untrusted data becomes part of a command or query interpreted by a database, shell, template engine, directory service, or another interpreter.

For SQL, use parameterized queries or prepared statements:

$stmt = $pdo->prepare(
    'SELECT * FROM customers WHERE email = :email'
);

$stmt->execute([
    'email' => $email
]);

Do not build SQL by concatenating raw user input.

Read the OWASP SQL Injection Prevention Cheat Sheet.

Input validation is not the only defence

Use:

  • Parameterized queries.
  • Allowlist validation for expected formats.
  • Least-privileged database accounts.
  • Framework or ORM functions used correctly.
  • Safe APIs instead of shell commands.
  • Context-appropriate encoding for output.

A WAF may block familiar payloads, but it cannot prove that a custom query is safe.

16. Prevent XSS, CSRF, Clickjacking, and Unsafe Browser Behaviour

Cross-site scripting occurs when untrusted content is rendered as executable code in another user’s browser. The result can include account impersonation, data theft, malicious redirects, fake login forms, or actions performed as the victim.

Use:

  • Framework auto-escaping.
  • Context-aware output encoding.
  • Sanitization for intentionally allowed HTML.
  • Safe DOM APIs such as textContent rather than inserting raw HTML.
  • A carefully deployed Content Security Policy.
  • HttpOnly, Secure, and SameSite cookies.

The OWASP XSS Prevention Cheat Sheet explains why no single defence is enough.

Protect state-changing requests from CSRF

A logged-in browser may automatically include session cookies when another website causes it to send a request.

Use:

  • Framework CSRF protection.
  • Anti-CSRF tokens.
  • SameSite cookie settings.
  • Origin or referer validation where appropriate.
  • Reauthentication for highly sensitive actions.

Do not perform account deletion, email changes, password changes, transfers, or administrator creation through a simple GET request.

Prevent clickjacking

Use CSP frame-ancestors or an appropriate X-Frame-Options policy so an attacker cannot invisibly frame sensitive pages and trick the visitor into clicking them.

17. Treat Every File Upload as Untrusted

Uploads are not automatically unsafe, but they require deliberate controls. An attacker may disguise executable code as an image, exploit a parser, overwrite an existing file, upload a huge archive, or create content that attacks another visitor.

Follow the OWASP File Upload Cheat Sheet.

Secure upload handling

  • Allow only file types required by the feature.
  • Validate extension, MIME type, file signature, and actual content.
  • Generate a random server-side filename.
  • Set strict file-size and request limits.
  • Store uploads outside the web root or in non-executable object storage where possible.
  • Prevent script execution in upload directories.
  • Scan files with current security tools.
  • Re-encode images rather than trusting the original file.
  • Use content disarm and reconstruction for risky document types when appropriate.
  • Protect download access with authorization checks.
  • Rate-limit upload endpoints.
  • Handle compressed archives carefully to prevent decompression bombs and path traversal.

Do not trust a filename ending in .jpg. Do not trust the browser-supplied MIME type. Do not place a user-chosen filename directly into a public path.

18. Secure Forms, APIs, Webhooks, and Password Resets

A contact form can become a spam relay. A search box can consume server resources. A webhook can create duplicate orders. A password-reset feature can reveal which customers have accounts.

Forms

  • Validate on the server, not only with browser JavaScript.
  • Limit field length and accepted formats.
  • Rate-limit submissions.
  • Use anti-automation controls appropriate to the risk.
  • Escape form data before displaying it.
  • Prevent email-header injection.
  • Do not include passwords or sensitive secrets in notification emails.

Browser autofill is not a general website backdoor. The security problem is an attacker controlling the device, browser profile, or account—not the mere existence of an autocomplete attribute. Configure sensitive fields appropriately, but focus on device security, session protection, and authentication.

APIs

  • Authenticate and authorize each request.
  • Validate content type and schema.
  • Limit request size, rate, and complexity.
  • Use short-lived scoped tokens where possible.
  • Do not expose private fields merely because the front end ignores them.
  • Prevent unrestricted cross-origin access.
  • Log abuse without logging secrets.

Webhooks

  • Verify a cryptographic signature from the provider.
  • Use HTTPS.
  • Reject stale or replayed events.
  • Make processing idempotent so duplicate delivery does not create duplicate charges or orders.
  • Do not trust an IP address alone when signed verification is available.

Password reset

Use single-use, time-limited, random reset tokens. Return similar responses whether or not an account exists. Do not email the existing password. Invalidate relevant sessions after a successful reset when the risk warrants it.

19. Protect Website Email and Stop Domain Impersonation

A secure website can still lose customer trust when attackers send convincing email from a lookalike or poorly protected domain.

Protect:

  • Hosting email accounts.
  • Transactional email provider.
  • SMTP credentials.
  • Newsletter platform.
  • Support inboxes.
  • Domain DNS records.

Configure email authentication

Use:

  • SPF to identify permitted sending systems.
  • DKIM to cryptographically sign outgoing messages.
  • DMARC to define handling and reporting for messages that fail alignment.

Begin DMARC with reporting, identify every legitimate sender, then move toward enforcement. A rushed reject policy can block your own order confirmations and password-reset messages.

Use unique API credentials for each email service and environment. Rotate them when staff, agencies, or providers change.

For broader protection against impersonation, fake invoices, and social engineering, see our complete online fraud prevention guide.

20. Build Backups That Survive the Same Attack as the Website

A backup stored inside the same hosting account with the same administrator credentials is useful for accidental deletion but may disappear during a serious compromise.

A strong strategy includes:

  • Automatic backups.
  • Several restore points covering different dates.
  • A copy outside the production hosting account.
  • Encryption for sensitive backup data.
  • Restricted deletion and administration.
  • MFA for the backup service.
  • Alerts when backups fail.
  • Regular restore tests.

CISA recommends offline or protected backups and regular recovery testing. The NCSC also publishes principles for ransomware-resistant backups.

Back up the complete service

Depending on the website, recovery may require:

  • Database.
  • Uploaded media.
  • Application code.
  • Configuration.
  • DNS records.
  • Web-server rules.
  • Scheduled tasks.
  • Email templates.
  • Encryption keys and documented secret-recovery procedures.

A database-only backup will not restore uploaded images. A file-only backup will not restore orders, accounts, posts, or settings.

Test restoration

A green “backup completed” message proves only that a job ran. Periodically restore into an isolated environment and verify:

  • The archive is readable.
  • The database imports.
  • The site starts.
  • Logins work.
  • Images load.
  • Checkout, forms, and scheduled tasks work.

Keep older restore points. Malware may remain unnoticed long enough to infect every recent daily backup.

21. Log Important Events and Create Alerts Someone Will Read

Logs help answer:

  • When did the compromise begin?
  • Which account logged in?
  • What IP address and user agent were used?
  • Which file changed?
  • Was a plugin installed?
  • Was data exported?
  • Did the attacker create persistence?

Use the OWASP Logging Cheat Sheet when designing application logs.

Log security-relevant events

Examples:

  • Successful and failed administrator logins.
  • MFA, password, email, role, and recovery changes.
  • Administrator creation and deletion.
  • Plugin, theme, extension, and package installation.
  • File changes in executable directories.
  • Unexpected scheduled tasks.
  • Large exports and unusual API usage.
  • Payment and webhook verification failures.
  • WAF blocks and rate-limit events.
  • Backup deletion or configuration changes.

Do not log passwords, authentication codes, session tokens, payment-card data, private keys, or full sensitive request bodies.

Send important logs away from the server

An attacker with server access may delete local evidence. Forward important logs to a protected external service where practical.

Set retention according to the site’s risk, legal requirements, storage limits, and incident-response needs.

22. Monitor Uptime, Files, DNS, Certificates, Malware, and Search Results

Monitoring should detect meaningful changes rather than produce hundreds of ignored emails.

Monitor:

  • Uptime and response time.
  • TLS certificate expiration.
  • Domain expiration and nameserver changes.
  • DNS records.
  • Administrator accounts.
  • Core file integrity.
  • New executable files in upload or cache directories.
  • Unexpected redirects.
  • Spam pages appearing in search results.
  • Changes to checkout and payment scripts.
  • Outbound email volume.
  • CPU, memory, disk, and database anomalies.
  • Backup success and restore-test results.

Use more than an external homepage scan

An external scanner may miss:

  • A backdoor activated only by a special request.
  • Malware visible only to search-engine crawlers.
  • A stolen administrator account with no current file changes.
  • Database-injected JavaScript.
  • A scheduled task that reinfects clean files.

Combine external monitoring with server-side file, database, account, task, and log monitoring.

23. Secure Staging, Development, CI/CD, and Source-Code Repositories

Staging sites are often weaker than production but contain the same code, database, personal information, and secrets.

Protect staging with:

  • Authentication or network restrictions.
  • Noindex directives for search privacy—but never treat noindex or robots.txt as access control.
  • Separate credentials and secrets.
  • Sanitized production data.
  • Updates and monitoring.
  • Disabled real payment and email sending.

A robots.txt rule is public and voluntary. It can ask compliant crawlers not to index a URL; it cannot block attackers from opening that URL.

Protect source control and deployments

  • Require MFA.
  • Use branch protection and peer review.
  • Restrict who can change deployment workflows.
  • Scan commits for secrets.
  • Use short-lived deployment credentials where possible.
  • Pin third-party CI actions and review updates.
  • Separate production approval from ordinary development access for high-risk systems.
  • Record what version is currently deployed.

Do not expose .git, build artifacts, debug endpoints, source maps containing secrets, or deployment files through the public web server.

24. Add Extra Controls for E-Commerce and Membership Websites

Sites handling accounts, orders, subscriptions, payments, health information, or valuable private content need stronger controls.

Minimize sensitive data

The safest database record is one you never collected.

  • Use established payment providers and hosted payment fields where appropriate.
  • Do not store full card data unless the business is prepared for the resulting compliance obligations.
  • Delete personal data when it is no longer required.
  • Encrypt sensitive data at rest where appropriate.
  • Restrict exports.
  • Log administrator access to customer data.

Protect checkout integrity

Monitor:

  • Changes to payment JavaScript.
  • New external script domains.
  • Modified checkout templates.
  • Unexpected administrator or API users.
  • Changed bank or payout information.
  • New webhooks and payment integrations.

Use CSP, subresource integrity when practical, dependency control, change review, and file monitoring to reduce web-skimming risk.

Separate customer and administrator security

Administrators should use stronger MFA and shorter sensitive-session timeouts. Customers need secure password reset, session management, anti-automation controls, and clear alerts for high-risk changes.

25. Control Agencies, Developers, Employees, and Former Staff

Many breaches begin with a legitimate account that should have been removed or never needed broad access.

Onboarding

  • Create an individual account; do not share the owner’s login.
  • Assign the minimum required role.
  • Require MFA.
  • Set an expiry date for temporary access.
  • Record which systems the person can access.
  • Explain how incidents and suspicious messages must be reported.

Offboarding

Remove or rotate:

  • CMS and hosting users.
  • Registrar and DNS access.
  • Source repository and CI/CD access.
  • SSH keys.
  • Password-manager sharing.
  • API tokens and app passwords.
  • Email, analytics, advertising, payments, backups, and cloud access.

Do this when access ends, not during an annual cleanup.

Verify payment and DNS changes out of band

A compromised agency or employee inbox may request:

  • New bank details.
  • A DNS change.
  • An administrator account.
  • A new plugin or tracking script.
  • Remote access.

Verify high-impact changes through a known second channel. This is where website security and fraud prevention meet.

26. Test Security Instead of Assuming It Works

A site can have a WAF, security plugin, and backup service while still failing at the moment they are needed.

Safe owner checks

Regularly verify:

  • MFA works and recovery codes are available.
  • Former users cannot log in.
  • Backups restore.
  • HTTP redirects to HTTPS.
  • Certificates renew.
  • Security headers are present and do not break the site.
  • Admin and API endpoints are rate-limited.
  • Private files require authorization.
  • Staging is not public.
  • Alerts reach a monitored mailbox or ticket system.

Automated application testing

For custom applications, combine:

  • Static application security testing.
  • Dynamic testing.
  • Dependency and container scanning.
  • Secret scanning.
  • Infrastructure and cloud-configuration checks.
  • Manual code review.

Professional penetration testing

Use an authorized professional for important applications, custom authentication, payment workflows, APIs, multi-tenant systems, and sites holding sensitive information.

Define scope, written permission, test windows, data-handling rules, and emergency contacts. Never run aggressive scanners against infrastructure you do not own or lack permission to test.

27. Find the Backdoor When Malware Keeps Returning

Deleting the visible spam file is not enough if the original vulnerability, stolen account, scheduled task, database payload, or hidden backdoor remains.

Recurring malware may come from:

  • An unpatched vulnerable plugin or theme.
  • A stolen hosting, WordPress, SFTP, SSH, or email credential.
  • A hidden administrator account.
  • A malicious must-use plugin.
  • A modified core file.
  • A scheduled task or cron job.
  • A database-injected script.
  • An infected local computer stealing new credentials.
  • Another compromised website under the same hosting user.
  • A writable backup that restores the infection.
  • A server-level compromise outside the individual site.

Do not repeat the cycle of scanning, deleting one file, and declaring the site clean. Identify persistence and root cause.

Our dedicated guide explains how to remove malware that keeps returning and investigate common reinfection routes.

What to Do If Your Website Is Hacked

Do not begin by randomly deleting files. Preserve enough evidence to understand the breach, but move quickly enough to protect visitors and data.

1. Confirm and contain

  • Put the site into a safe maintenance state when continued operation threatens visitors.
  • Block malicious redirects, downloads, and payment pages.
  • Preserve logs, suspicious files, timestamps, database changes, and alerts.
  • Contact the host and relevant security provider.
  • Do not alert the attacker through an obviously monitored channel if doing so would worsen the incident.

2. Use a clean administrative device

Do not change every password from a laptop that may contain a keylogger or stolen browser session. Update and scan the device, or use another trusted system.

3. Secure the control plane first

Reset and review:

  1. Primary email.
  2. Domain registrar.
  3. DNS and CDN.
  4. Hosting and cloud account.
  5. CMS administrators.
  6. SFTP, SSH, database, repositories, CI/CD, and backups.

Enable MFA, terminate sessions, revoke unknown devices, and remove unauthorized users.

4. Determine the scope

Check:

  • Files and database.
  • Other sites under the same account.
  • Administrator users.
  • Scheduled tasks.
  • DNS and certificates.
  • Email accounts and forwarding rules.
  • Payment and advertising accounts.
  • Logs and outbound traffic.
  • Backups and staging sites.

5. Rebuild from known-good sources

For WordPress, replace core files with official clean copies. Reinstall plugins and themes from trusted sources rather than assuming every existing file is safe.

For custom applications, redeploy a reviewed clean build from source control. Restore user content and database data carefully. A full restore from backup is only safe when the backup predates the compromise and the original vulnerability has been closed.

6. Remove persistence

Look for:

  • Hidden users.
  • New SSH keys.
  • Modified startup scripts.
  • Scheduled tasks.
  • Unknown plugins and PHP files.
  • Injected database content.
  • Malicious DNS records.
  • OAuth applications and API tokens.

7. Patch the entry point

A clean site with the same vulnerable plugin, leaked password, public staging copy, or unrestricted upload endpoint will be compromised again.

Document the most likely root cause and the evidence supporting it. When the cause cannot be established confidently, rebuild more broadly and increase monitoring.

8. Rotate secrets

Rotate exposed or potentially exposed:

  • Passwords.
  • Database credentials.
  • API keys.
  • Payment and email tokens.
  • SSH keys.
  • WordPress authentication salts when appropriate after a compromise.
  • Webhook secrets.

9. Meet legal and contractual obligations

If personal, payment, health, employee, or customer data may have been exposed, contact qualified legal, privacy, insurance, and incident-response professionals. Notification duties vary by country, industry, contract, and type of data.

10. Watch for the attacker’s return

Increase monitoring for logins, file changes, DNS edits, password resets, outgoing email, new administrators, checkout modifications, and unusual traffic.

Remove Browser Warnings and Search-Engine Security Flags

A compromised site may receive browser warnings, Search Console security reports, spam pages in search, or reduced trust from visitors.

Use the Google Search Console Security Issues report to understand detected problems.

Before requesting a review:

  1. Remove malicious content and redirects.
  2. Close the exploited vulnerability.
  3. Remove backdoors and unauthorized users.
  4. Secure related accounts and devices.
  5. Verify important pages and external resources.
  6. Explain clearly what was cleaned and what control now prevents recurrence.

Do not request review after deleting only the visible hacked URL. Google may detect hidden or recurring behaviour and reject the review.

Search results can take time to recrawl and update after the site is clean.

Website Security Maintenance Schedule

Continuous or automatic

  • Uptime monitoring.
  • Certificate monitoring.
  • Backup jobs and failure alerts.
  • WAF and rate-limit protection.
  • Important login and administrator-change alerts.
  • Dependency and vulnerability notifications.

Daily

  • Investigate critical security alerts.
  • Check failed backups and unusual outages.
  • Review unexpected administrator or payment changes.

Weekly

  • Apply available security updates.
  • Review suspicious login and WAF activity.
  • Check malware and file-integrity results.
  • Review unusual outbound email and resource usage.

Monthly

  • Review users, roles, API tokens, and integrations.
  • Delete unused plugins, themes, packages, and staging copies.
  • Verify domain, DNS, certificate, and backup status.
  • Review Search Console security and indexing anomalies.

Quarterly

  • Perform a documented restore test.
  • Review the asset inventory.
  • Test incident contacts and recovery access.
  • Review firewall, CSP, permissions, and log-retention policies.
  • Remove access for completed projects and former staff.

Annually or after major architectural changes

  • Review the threat model.
  • Commission appropriate security testing.
  • Review privacy, data retention, and breach procedures.
  • Evaluate the host, plugins, dependencies, and vendors.
  • Run an incident-response exercise.

Complete Website Security Checklist

  • Maintain an inventory of domains, subdomains, hosts, applications, dependencies, users, and integrations.
  • Enable MFA or passkeys on registrar, DNS, hosting, CMS, email, code, backups, and cloud accounts.
  • Use unique passwords stored in a password manager.
  • Enable domain transfer lock and change notifications.
  • Use DNSSEC where properly supported.
  • Run supported server, runtime, CMS, plugin, theme, and package versions.
  • Remove unused software, accounts, services, ports, and test sites.
  • Install code only from trusted sources.
  • Monitor dependencies and actively exploited vulnerabilities.
  • Separate unrelated websites and databases where practical.
  • Use SFTP or SSH instead of plain FTP.
  • Apply least privilege to users, files, databases, cloud roles, and API tokens.
  • Disable WordPress dashboard file editing when not needed.
  • Protect configuration, environment, backup, log, and Git files from public access.
  • Use a WAF, rate limits, bot controls, CDN, and DDoS protection appropriate to the site.
  • Restrict direct access to the origin server where practical.
  • Use HTTPS everywhere and automate certificate renewal.
  • Deploy tested CSP, HSTS, MIME, referrer, permissions, framing, and secure-cookie controls.
  • Use parameterized queries and safe framework APIs.
  • Encode output and sanitize intentionally allowed HTML.
  • Use CSRF protection on state-changing actions.
  • Validate authorization on every private object and API request.
  • Restrict and isolate file uploads.
  • Secure forms, password resets, APIs, and webhooks.
  • Keep secrets out of source code, browser JavaScript, logs, and public repositories.
  • Configure SPF, DKIM, and DMARC for website email.
  • Keep automated, encrypted, off-site, and protected backups with several restore points.
  • Test backup restoration.
  • Log and alert on important security events.
  • Monitor uptime, files, accounts, DNS, certificates, malware, search results, and payment changes.
  • Protect staging, source control, and CI/CD as strongly as production.
  • Remove access immediately when staff, agencies, or contractors leave.
  • Verify high-impact requests through a second channel.
  • Test security controls regularly.
  • Maintain a written incident-response and recovery plan.

Frequently Asked Questions

Can a website be made completely unhackable?

No. Software defects, stolen accounts, provider incidents, human mistakes, and new attack methods can never be reduced to zero. A strong security programme lowers probability, limits damage, detects compromise quickly, and supports clean recovery.

What is the single most important website security action?

There is no single control, but updating exposed software and protecting administrator accounts with MFA close two of the most common routes. Tested off-site backups are equally important because prevention can still fail.

Is WordPress secure?

WordPress can be operated securely when core, plugins, themes, hosting, administrator accounts, permissions, and backups are maintained. Risk often comes from vulnerable or abandoned extensions, nulled software, weak credentials, excessive administrators, and neglected hosting accounts.

Do I need a WordPress security plugin?

Not every site requires the same plugin, but many owners benefit from carefully selected login protection, audit logs, malware scanning, and file monitoring. A plugin does not replace updates, MFA, hosting security, DNS protection, WAF controls, clean devices, or backups.

Is changing the WordPress login URL enough?

No. It may reduce automated noise, but the URL can still be discovered and it does not repair vulnerable code. Use MFA, rate limiting, strong credentials, updates, monitoring, and a WAF.

Should I change the WordPress database prefix?

It can interfere with basic automated assumptions, but it is minor security through obscurity. It does not prevent SQL injection in vulnerable code and should not be treated as a primary defence.

Should passwords be changed every 60 or 90 days?

Not automatically for every user. Prefer long unique passwords, password managers, MFA, and breach monitoring. Change passwords when they are weak, reused, shared, exposed, phished, or connected with suspected compromise, unless a specific regulatory requirement says otherwise.

Is HTTPS enough to stop hacking?

No. HTTPS encrypts the connection. It does not patch plugins, secure administrator accounts, prevent malicious uploads, correct access-control bugs, or remove malware from the server.

Does robots.txt protect the admin area?

No. The file is public and compliant crawlers may obey it, but attackers do not have to. Use authentication, authorization, network controls, MFA, and server configuration. Use noindex only for indexing behaviour, not security.

Does disabling right-click protect website code?

No. Browsers must receive HTML, CSS, JavaScript, images, and other public resources to display the page. Disabling right-click harms usability and does not stop someone from viewing or saving client-side code.

Does browser autofill make a form vulnerable to SQL injection?

No. SQL injection is caused by unsafe server-side query construction, not by autofill. Use parameterized queries, server-side validation, least privilege, and safe framework APIs.

How often should a website be backed up?

The schedule should match how much data the business can afford to lose. A static brochure site may use daily or weekly backups, while a busy shop or membership site may require frequent database backups. Keep several restore points and test them.

Where should website backups be stored?

Keep at least one protected copy outside the live hosting account. Use separate credentials, MFA, encryption, restricted deletion, and multiple historical restore points.

Can a WAF stop every attack?

No. A WAF can block many common attacks and abusive requests, but it cannot reliably repair broken authorization, insecure business logic, stolen administrator sessions, malicious dependencies, or compromised hosting accounts.

How do I know whether my website has been hacked?

Warning signs include unknown administrators, changed files, spam pages in search, strange redirects, browser warnings, unexpected scheduled tasks, high CPU usage, outbound spam, modified checkout code, unfamiliar DNS records, and repeated malware detections.

Why does malware return after I remove it?

The original vulnerability or persistence mechanism remains. Common causes include an unpatched plugin, hidden backdoor, stolen credentials, malicious scheduled task, infected database content, compromised local device, sibling site infection, or unsafe backup.

Should I restore a hacked site from backup?

A known-clean backup can help, but first determine whether it predates the compromise and close the entry point. Restoring an infected backup or restoring into the same vulnerable environment can recreate the incident.

When should I hire a website security professional?

Get qualified help when the site processes payments or sensitive data, malware returns, administrator control is lost, multiple sites or servers are affected, the root cause is unclear, customer data may be exposed, or business operations depend on rapid recovery.

What should I do first if a website is actively redirecting visitors to malware?

Protect visitors immediately by taking the affected service offline or placing it into a safe maintenance state. Preserve evidence, contact the host, use a clean device, secure registrar and hosting accounts, and begin a controlled incident response.

Can a hacked website damage SEO?

Yes. Attackers may create spam pages, redirects, phishing content, malware downloads, or deceptive pages. Search engines and browsers can display warnings or remove harmful results until the problem is fixed and reviewed.

Final Verdict

The best website security is deliberately boring: updates happen before a crisis, former users lose access on time, backups restore when tested, alerts reach someone who reads them, and no single stolen password controls the entire business.

Begin with the highest-value layers. Protect the domain, email, hosting, and administrator accounts with strong MFA. Keep the entire software stack supported and patched. Remove components you do not need. Put sensible WAF and rate-limit controls in front of public endpoints. Use secure coding practices, strict upload handling, least privilege, protected secrets, reliable logging, and off-site backups.

Then prepare for the possibility that one layer will fail. Monitor changes, preserve evidence, isolate unrelated systems, document recovery, and know how to rebuild from trusted sources.

A website is not secured once. It remains secure only while its software, people, accounts, vendors, data, and recovery process are actively maintained.

Related Posts:
>> How to Protect Facebook Account From Hacking
>> How to Protect Instagram Account From Hacking

Thanks for reading and see you guys soon in the next post! <3