Attackers do not always manually choose their targets. Automated bots continuously scan websites for outdated plugins, weak passwords, exposed files, vulnerable software, insecure APIs, forgotten subdomains, and server misconfigurations.
That is why website security should be treated as an ongoing process rather than a one-time setup.
This website security checklist covers 50 important areas—from HTTPS and malware protection to WordPress security, DNS, email authentication, backups, monitoring, and incident response.
Complete 50-Point Website Security Checklist
| Sr No. | Security Check | What to Verify | Recommended Result | Priority |
| 1 | HTTPS | Entire website loads securely | HTTPS everywhere | Critical |
| 2 | SSL/TLS Certificate | Validity, hostname, expiry | Valid and auto-renewing | Critical |
| 3 | HTTP to HTTPS Redirect | HTTP requests redirect securely | Permanent HTTPS redirect | High |
| 4 | Google Safe Browsing | Domain reputation | No unsafe content | High |
| 5 | Malware Scanning | Malicious files or code | No malware detected | Critical |
| 6 | Virus/Reputation Scan | Multiple security vendors | No detections | High |
| 7 | Domain Blacklist | Reputation databases | Not blacklisted | High |
| 8 | Security Headers | Browser security controls | Properly configured | High |
| 9 | Content Security Policy | Allowed resource sources | Restrictive, tested CSP | High |
| 10 | HSTS | HTTPS enforcement | Properly configured | High |
| 11 | Clickjacking Protection | Framing restrictions | Protected | Medium |
| 12 | MIME Sniffing Protection | Content type handling | nosniff | Medium |
| 13 | Referrer Policy | Referrer data exposure | Appropriate policy | Medium |
| 14 | Permissions Policy | Browser feature access | Restricted as required | Medium |
| 15 | CMS Updates | WordPress or other CMS | Current supported version | Critical |
| 16 | Plugin Security | Known vulnerabilities | No vulnerable plugins | Critical |
| 17 | Theme Security | Known vulnerabilities | Updated and maintained | High |
| 18 | Unused Software | Plugins/themes/packages | Removed | Medium |
| 19 | Admin Security | Privileged accounts | Restricted | Critical |
| 20 | MFA/2FA | Administrator authentication | Enabled | Critical |
| 21 | Password Security | Password strength/reuse | Strong and unique | Critical |
| 22 | Login Rate Limiting | Automated login attempts | Restricted | High |
| 23 | File Permissions | Server files/directories | Least privilege | High |
| 24 | .env Exposure | Environment secrets | Not publicly accessible | Critical |
| 25 | .git Exposure | Repository information | Not publicly accessible | Critical |
| 26 | Configuration Files | Credentials/settings | Protected | Critical |
| 27 | Backup File Exposure | ZIP/SQL/archive files | Not publicly accessible | Critical |
| 28 | Directory Listing | Directory contents | Disabled unless required | Medium |
| 29 | Database Security | Credentials/network access | Restricted | Critical |
| 30 | API Security | Authentication/authorization | Properly protected | Critical |
| 31 | CORS | Cross-origin access | Least privilege | High |
| 32 | Cookies | Session protection | Secure attributes | High |
| 33 | WAF | Application-layer filtering | Enabled where appropriate | High |
| 34 | DDoS Protection | Traffic attacks | Mitigation available | High |
| 35 | DNSSEC | DNS integrity | Enabled where supported | Medium |
| 36 | Subdomain Security | Old/dangling records | No abandoned services | High |
| 37 | Subdomain Takeover | Dangling DNS | None | High |
| 38 | SPF | Authorized email senders | Correctly configured | High |
| 39 | DKIM | Email authentication | Valid | High |
| 40 | DMARC | Anti-spoofing policy | Configured and monitored | High |
| 41 | Backups | Website/database copies | Automated and protected | Critical |
| 42 | Restore Testing | Backup usability | Regularly tested | Critical |
| 43 | Logging | Security events | Enabled | High |
| 44 | Monitoring | Attacks/changes/outages | Active | High |
| 45 | Vulnerability Scanning | Known weaknesses | Regular scans | High |
| 46 | Server Runtime | PHP/Node/etc. | Supported version | Critical |
| 47 | Version Disclosure | Technology information | Minimized | Low |
| 48 | Staging Sites | Development environments | Private/protected | High |
| 49 | Third-Party Scripts | External JavaScript/services | Reviewed and necessary | High |
| 50 | Incident Response | Compromise procedure | Documented and tested | High |
Want to download the 50-Site Security Checklist?
Click here
Let’s See 50 Terms of Website Security
1. Use HTTPS Across the Entire Website
HTTPS encrypts information transmitted between a visitor’s browser and your web server.
Without HTTPS, traffic may be vulnerable to interception or modification under certain network conditions.
Your website should therefore use:
https://example.com
rather than relying on:
http://example.com/
HTTPS should apply to the entire website—not just login, checkout, or contact pages.
What to check
Make sure:
- every public page works over HTTPS;
- internal links use HTTPS;
- images, scripts and stylesheets do not unnecessarily load over HTTP;
- canonical URLs use HTTPS;
- sitemaps contain HTTPS URLs.
HTTPS is an essential security baseline, but remember that HTTPS alone does not mean a website is secure. It protects data in transit; it does not fix vulnerable software or compromised accounts.
2. Verify Your SSL/TLS Certificate
HTTPS depends on a valid TLS certificate.
Check that the certificate:
- has not expired;
- covers the correct hostname;
- is issued by a trusted certificate authority;
- uses an appropriate certificate chain;
- renews automatically where possible.
For example, if visitors use both:
example.com
and
www.example.com
your certificate and web configuration should properly handle the hostnames you support.
Useful tool
Qualys SSL Labs:
https://www.ssllabs.com/ssltest/
SSL Labs can provide a much deeper TLS assessment than simply checking whether the browser shows a padlock.
3. Redirect HTTP Traffic to HTTPS
Even after installing an SSL/TLS certificate, users may still reach an old HTTP URL.
For example:
http://example.com/page/
should be redirected to:
https://example.com/page
A permanent redirect is commonly appropriate when the HTTPS URL is the permanent canonical version.
Also check for redirect chains
Avoid configurations such as:
HTTP → HTTPS www → HTTPS non-www → final URL
when a single direct redirect can accomplish the same result.
Unnecessary chains add complexity and latency.
4. Check Google Safe Browsing
Google Safe Browsing identifies websites associated with certain unsafe or deceptive activity.
You can check your website using:
Google Transparency Report:
https://transparencyreport.google.com/safe-browsing/search
A healthy result should indicate that no unsafe content is currently known for the tested site.
If your site is flagged
Investigate before requesting a review.
Look for:
- malicious code;
- phishing pages;
- compromised administrator accounts;
- injected scripts;
- suspicious redirects;
- compromised plugins;
- unauthorized downloads.
A review request should come after remediation, not instead of remediation.
5. Scan Your Website for Malware
Malware does not always produce an obvious visual change.
A compromised website might:
- redirect selected visitors;
- inject spam links;
- create hidden pages;
- steal login information;
- load malicious JavaScript;
- distribute unwanted files.
Useful tool
Sucuri SiteCheck:
https://sitecheck.sucuri.net/
External malware scanning is useful for detecting publicly observable problems.
However, an external scan cannot necessarily inspect every server-side file or database record.
For higher-risk sites, combine external scanning with server-side malware detection, file-integrity monitoring, and log review.
6. Perform a Multi-Vendor Virus and Reputation Scan
Different security vendors use different detection systems.
A multi-vendor service can therefore provide additional context about a URL or domain.
Useful tool
VirusTotal:
https://www.virustotal.com/
A result showing no detections across numerous reputable engines is a positive signal.
However:
0 detections does not guarantee zero vulnerabilities.
A site can be free of known malware while still containing an exploitable plugin or configuration mistake.
7. Check Domain Blacklists
Security and reputation providers may flag domains associated with malware, phishing, spam, or other abusive behavior.
Blacklist problems can affect:
- visitor trust;
- email deliverability;
- browser warnings;
- marketing campaigns;
- business reputation.
Useful services include:
- Google Safe Browsing;
- VirusTotal;
- Sucuri;
- MXToolbox.
If your domain appears on a blacklist, first determine why it was listed. Fix the root cause before requesting delisting.
8. Configure Security Headers
HTTP security headers instruct browsers to apply additional security rules.
Common headers include:
- Content-Security-Policy;
- Strict-Transport-Security;
- X-Content-Type-Options;
- X-Frame-Options;
- Referrer-Policy;
- Permissions-Policy.
Useful tool
SecurityHeaders:
https://securityheaders.com/
Don’t test only your homepage
A homepage may have excellent headers while another part of the website does not.
Test representative URLs such as:
https://example.com
https://example.com/blog
https://example.com/tools
https://example.com/account
Different server rules, applications, proxies, caches, or subdomains can produce different headers.
9. Implement a Strong Content Security Policy
Content Security Policy, or CSP, controls which sources a browser may use for resources such as:
- JavaScript;
- CSS;
- images;
- fonts;
- frames;
- network connections.
A properly designed CSP can reduce the impact of certain content-injection and cross-site scripting attacks.
But simply having a CSP header is not enough.
An overly permissive CSP may offer limited protection.
Good practice
Build the policy around the resources your website genuinely needs.
For complex sites, consider testing with Content-Security-Policy-Report-Only before enforcing a stricter policy so legitimate functionality is not accidentally broken.
10. Configure HSTS
HTTP Strict Transport Security, or HSTS, tells compatible browsers to use HTTPS for a domain after receiving the policy securely.
A typical header may resemble:
Strict-Transport-Security: max-age=31536000
Additional options can apply the policy to subdomains.
Be careful
Do not blindly enable includeSubDomains or HSTS preload.
If one of your subdomains cannot operate correctly over HTTPS, an overly broad HSTS policy can create availability problems.
Test your HTTPS architecture before increasing the scope.
11. Protect Against Clickjacking
Clickjacking occurs when an attacker attempts to display a legitimate page inside another interface and tricks the visitor into interacting with it.
Framing restrictions can be implemented using:
Content-Security-Policy frame-ancestors
and, where appropriate:
X-Frame-Options
The correct configuration depends on whether your website legitimately needs to be embedded in other websites.
12. Prevent MIME-Type Sniffing
Browsers sometimes attempt to infer the content type of a response.
The header:
X-Content-Type-Options: nosniff
tells compatible browsers not to MIME-sniff supported responses away from their declared content type.
Status to aim for
X-Content-Type-Options: nosniff
This is a straightforward hardening measure for many websites.
13. Configure Referrer Policy
When users navigate between pages, browsers may send information about the referring page.
Referrer-Policy gives websites control over how much referrer information is shared in different navigation scenarios.
The right policy depends on your site’s requirements.
The objective is to avoid unnecessarily exposing URL information while preserving legitimate analytics or application functionality where required.
14. Configure Permissions Policy
Permissions Policy lets websites control access to selected browser features.
Depending on browser support and site requirements, this may include capabilities such as:
- camera;
- microphone;
- geolocation;
- fullscreen;
- other controlled features.
If your site never uses a capability, there may be no reason to make it broadly available.
Configure the policy according to actual functionality rather than copying an arbitrary header from another website.
15. Keep Your CMS Updated
If your site uses WordPress, Drupal, Joomla, or another CMS, keep it on a supported and patched release.
Security vulnerabilities are regularly discovered in software.
Once a vulnerability becomes public, automated attackers may begin looking for websites still running affected versions.
Before major upgrades
For business-critical sites:
- create a backup;
- verify plugin/theme compatibility;
- test where appropriate;
- deploy the update;
- confirm important functionality afterwards.
Do not use compatibility concerns as a reason to leave known security vulnerabilities unresolved indefinitely.
16. Audit Plugin Security
Plugins extend functionality, but they also expand the website’s attack surface.
For each plugin, ask:
- Is it actively maintained?
- Is the installed version current?
- Are there known security vulnerabilities?
- Is it still required?
- Is it from a trustworthy source?
WordPress users
WPScan and vulnerability databases can help identify known plugin vulnerabilities.
Security advisories from plugin developers and reputable vulnerability databases are also useful.
A vulnerable plugin should be updated, replaced, mitigated, or removed based on the risk.
17. Audit Theme Security
Themes can contain PHP, JavaScript, dependencies, and application logic.
They therefore need the same security attention as plugins.
Check:
- current version;
- known vulnerabilities;
- developer maintenance;
- parent/child theme dependencies;
- unnecessary old themes.
Do not assume a theme is harmless simply because it controls visual design.
18. Remove Unused Software
Unused plugins, themes, libraries, packages, scripts, and old applications increase attack surface.
If a component serves no legitimate purpose, consider removing it.
For example, a disabled WordPress plugin may still leave its files on the server.
Removing unnecessary software also makes:
- updates easier;
- monitoring simpler;
- vulnerability management more manageable.
Keep the production environment as lean as practical.
19. Secure Administrator Accounts
Administrator accounts have powerful permissions and therefore deserve stronger protection.
Review:
- who has administrator access;
- whether each account still needs it;
- former employees or contractors;
- service accounts;
- unnecessary privileges.
Apply the principle of least privilege.
Someone who only publishes articles should not automatically receive full administrator access.
20. Enable MFA or 2FA
Passwords can be stolen through:
- phishing;
- malware;
- credential reuse;
- data breaches;
- social engineering.
Multi-factor authentication adds another barrier.
For privileged accounts, enable MFA wherever the platform supports it.
Where available, phishing-resistant authentication methods such as passkeys or hardware security keys can provide stronger protection than passwords alone.
21. Use Strong, Unique Passwords
Never reuse important website passwords across unrelated services.
If another service is breached, attackers may test leaked credentials against your website.
Use:
- long passwords;
- unique credentials;
- a reputable password manager;
- secure password-reset procedures.
Avoid predictable passwords based on company names, domains, names, or years.
22. Implement Login Rate Limiting
Automated bots can make large numbers of login attempts.
Rate limiting can reduce brute-force and credential-stuffing attempts by restricting repeated requests.
Depending on the application, combine:
- rate limiting;
- MFA;
- WAF rules;
- bot detection;
- login monitoring.
Changing the login URL can sometimes reduce automated noise, but it should not be considered a substitute for proper authentication security.
23. Review File and Directory Permissions
Files and directories should have only the permissions required for the application to function.
Overly permissive permissions may allow unauthorized modification.
The correct values depend on:
- operating system;
- web server;
- hosting environment;
- deployment architecture.
Avoid blindly setting everything to globally writable permissions simply to solve an application error.
Follow the principle of least privilege.
24. Prevent .env File Exposure
Environment files often contain sensitive secrets such as:
DATABASE_PASSWORD=
API_KEY=
SMTP_PASSWORD=
SECRET_KEY=
A publicly downloadable .env file can lead to serious compromise.
A URL such as:
https://example.com/.env
must never expose those contents.
Where possible, store secrets outside publicly accessible directories and use appropriate environment/secret-management mechanisms.
25. Prevent .git Repository Exposure
A .git directory can reveal:
- source-code history;
- deleted code;
- internal paths;
- configuration;
- potentially committed secrets.
Production deployments should not unnecessarily expose repository metadata.
Check that requests to locations such as:
https://example.com/.git
cannot disclose repository contents.
If secrets were ever committed to a repository, simply hiding .git is not enough—affected credentials should be rotated.
26. Protect Configuration Files
Configuration files may contain:
- database credentials;
- API keys;
- authentication secrets;
- salts;
- internal infrastructure information.
For WordPress, wp-config.php is particularly sensitive.
For other frameworks, equivalent configuration and secret files require similar protection.
Sensitive configuration should never be served as ordinary public content.
27. Remove Publicly Accessible Backup Files
Backup files sometimes get left in public directories with names such as:
backup.zip
site-backup.zip
database.sql
db-backup.sql
old-site.zip
config.php.bak
If downloadable, these files may expose source code, personal data, credentials, or database contents.
Backups should be stored in appropriately protected locations—not casually left inside the public web root.
28. Disable Unnecessary Directory Listing
If directory indexing is enabled, visiting a directory may reveal its files.
For example:
https://example.com/uploads
might display a list of contents when no index page exists.
That can reveal:
- old files;
- scripts;
- backups;
- logs;
- internal filenames.
Disable directory listing unless publicly browsing directory contents is an intentional feature.
29. Secure the Database
Your database may contain some of the website’s most sensitive information.
Protect it with:
- strong unique credentials;
- least-privilege database accounts;
- restricted network access;
- supported database software;
- secure backups;
- encryption where appropriate;
- monitoring.
Do not expose a database directly to the public internet unless there is a specific architectural requirement and strong access controls.
30. Secure Your APIs
An API should independently verify whether a request is permitted.
Review four fundamental areas:
Authentication
Who is making the request?
Authorization
Is that user allowed to perform this action or access this record?
Validation
Is the submitted input expected and safe?
Rate limiting
Can the endpoint be abused through excessive requests?
Also review APIs for unnecessary data exposure, insecure direct object access, weak token handling, and improper error messages.
For API-heavy applications, use established guidance such as the OWASP API Security Top 10 as part of the review process.
31. Configure CORS Carefully
Cross-Origin Resource Sharing controls which web origins can access certain resources through browsers.
A configuration that is too permissive can create security problems, particularly when sensitive endpoints or credentials are involved.
Review:
- allowed origins;
- methods;
- headers;
- credentials;
- preflight behavior.
Do not use * simply because it fixes a browser error.
CORS should reflect your actual application architecture.
32. Protect Cookies
Session and authentication cookies should use appropriate security attributes.
Common controls include:
Secure
Restricts cookie transmission to HTTPS.
HttpOnly
Prevents normal JavaScript access to the cookie.
SameSite
Controls cookie behavior in cross-site requests.
A typical authentication cookie may require some combination of these attributes depending on the application’s architecture.
Do not copy cookie settings blindly; authentication flows involving third-party services may require specific behavior.
33. Use a Web Application Firewall Where Appropriate
A Web Application Firewall (WAF) analyzes web requests and can block or challenge suspicious traffic according to configured rules.
Depending on the product and setup, a WAF can help with:
- malicious bots;
- known attack patterns;
- abusive requests;
- rate limiting;
- virtual patching in some scenarios.
WAF capabilities are available through services such as Cloudflare, Sucuri, hosting providers, and other security platforms.
Remember
A WAF is an additional layer.
It does not justify leaving vulnerable software unpatched.
34. Prepare for DDoS Attacks
A Distributed Denial-of-Service attack attempts to overwhelm infrastructure or application resources.
Protection may involve:
- CDN/edge infrastructure;
- upstream DDoS mitigation;
- caching;
- rate limiting;
- WAF rules;
- scalable architecture;
- provider-level protections.
A personal blog and a large ecommerce platform will not require identical DDoS strategies.
Choose protection according to business impact and expected threat level.
35. Configure DNSSEC
DNSSEC adds cryptographic validation to DNS responses, helping protect against certain DNS spoofing and cache-poisoning scenarios.
Useful tool
DNSViz:
https://dnsviz.net/
DNSSEC typically requires correct configuration between the DNS hosting provider and the parent zone/registrar.
Incorrect DNSSEC can cause resolution failures, so changes should be carefully validated.
36. Audit All Subdomains
Organizations often accumulate subdomains over time:
blog.example.com
api.example.com
staging.example.com
dev.example.com
old.example.com
Some may eventually be forgotten.
Maintain an inventory that identifies:
- purpose;
- owner;
- hosting provider;
- DNS destination;
- SSL status;
- software;
- whether the subdomain is still required.
Delete obsolete DNS records when they are no longer needed.
37. Check for Subdomain Takeover Risk
A subdomain takeover can become possible in certain situations when DNS points to an external service that the organization no longer controls.
For example:
old.example.com → discontinued third-party resource
If the DNS record remains while the underlying resource is released, another party may potentially claim the resource depending on the provider.
Prevention
Regularly audit:
- CNAME records;
- cloud-hosting references;
- CDN configurations;
- SaaS integrations;
- abandoned projects.
Remove dangling DNS records promptly.
38. Configure SPF
Sender Policy Framework, or SPF, allows a domain to specify which mail systems are authorized to send mail on its behalf.
SPF is published through DNS.
It should accurately represent your real email infrastructure.
Common mistake
Adding every email service you have ever used can create an overly complex or invalid record.
Review SPF whenever email providers change.
SPF is only one part of email authentication and should generally be considered alongside DKIM and DMARC.
39. Configure DKIM
DomainKeys Identified Mail, or DKIM, cryptographically signs outgoing email.
Receiving mail systems can use a DNS-published public key to verify the signature.
DKIM helps establish that signed portions of a message were not altered after signing and associates the message with the signing domain.
Verify that:
- DKIM signing is enabled;
- selectors resolve correctly;
- keys are appropriately managed;
- legitimate mail services sign messages correctly.
40. Implement DMARC
DMARC works with SPF and DKIM to provide domain-level email authentication policy and reporting.
DMARC can help domain owners understand and reduce unauthorized email impersonation.
A deployment often begins with monitoring before moving toward stronger enforcement.
Important
Do not blindly publish a strict rejection policy before identifying every legitimate sender.
You could unintentionally block your own:
- newsletters;
- CRM emails;
- support systems;
- transactional messages.
Use DMARC reports to understand your email ecosystem first.
41. Maintain Automated Backups
Security includes recovery.
If your website is compromised, corrupted, deleted, or damaged by a failed update, a reliable backup can significantly reduce recovery time.
Back up:
- website files;
- database;
- important configuration;
- critical uploaded content.
The appropriate backup frequency depends on how often your data changes.
A busy ecommerce site may require a much shorter recovery point than a static informational site.
42. Test Backup Restoration
A backup is not truly trustworthy until you know it can be restored.
Periodically perform a controlled restoration test.
Verify:
- files restore;
- database restores;
- application starts correctly;
- login works;
- important functionality works;
- recent expected data exists.
Do this in an appropriate isolated environment rather than overwriting a healthy production site just to test a backup.
43. Enable Security Logging
Logs provide evidence of what happened before, during, and after a security incident.
Useful sources can include:
- web server access logs;
- server error logs;
- authentication logs;
- CMS activity logs;
- WAF events;
- API logs;
- cloud/CDN logs;
- administrator actions.
Logs should themselves be protected against unauthorized deletion or modification.
Retention should reflect business, security, legal, and privacy requirements.
44. Monitor Your Website Continuously
Logging records events. Monitoring helps you notice when those events matter.
Monitor for:
- downtime;
- unusual traffic;
- repeated failed logins;
- unexpected administrator accounts;
- file changes;
- malware detections;
- SSL problems;
- DNS changes;
- unusual server errors;
- WAF alerts.
For important websites, alerts should reach someone who can actually investigate them.
A security alert that nobody sees provides little protection.
45. Run Regular Vulnerability Scans
New vulnerabilities are discovered continuously.
A website that passed every scan last month can become vulnerable after a new issue is disclosed.
Regularly scan for:
- outdated software;
- known CVEs;
- plugin vulnerabilities;
- insecure configurations;
- exposed services;
- TLS weaknesses;
- web application issues.
Useful tools can include:
WPScan — WordPress vulnerabilities
OWASP ZAP — authorized web application testing
SSL Labs — TLS configuration
SecurityHeaders — HTTP headers
Sucuri — external website scanning
Only perform active security testing against systems you own or are authorized to test.
Don’t blindly trust scanner results
Scanners can produce:
false positives — reported problem does not apply;
and
false negatives — real problem is not detected.
Important findings should be validated.
46. Keep Server Runtime Software Supported and Updated
The CMS is only one layer of your technology stack.
Your website may depend on:
- PHP;
- Node.js;
- Python;
- Java;
- Apache;
- nginx;
- database software;
- operating-system packages;
- container images.
An updated WordPress installation running on an unsupported server runtime is still a security concern.
Check
- Is the runtime version still supported?
- Are security updates available?
- Are OS packages patched?
- Are unnecessary modules/services enabled?
- Does the hosting provider manage these updates?
Plan upgrades before a runtime reaches end of support.
47. Minimize Version Disclosure
Web servers and applications sometimes reveal software versions through HTTP headers, error pages, generated HTML, or public files.
For example:
PHP/8.x.x
Apache/x.x.x
nginx/x.x.x
Version disclosure is generally a lower-risk issue than actually running vulnerable software, but there is little reason to give attackers unnecessary reconnaissance information.
For PHP, one possible hardening setting is:
expose_php = Off
depending on your hosting environment.
Important distinction
Hiding a vulnerable version does not fix the vulnerability.
Updating and patching remain the priority.
48. Protect Staging and Development Websites
Staging environments frequently receive less security attention than production.
Examples include:
staging.example.com
dev.example.com
test.example.com
beta.example.com
These sites may contain:
- copies of production data;
- debugging information;
- weak test passwords;
- unfinished features;
- outdated software;
- development tools.
Where practical:
- restrict access;
- use separate credentials;
- avoid unnecessary production data;
- prevent search-engine indexing where appropriate;
- keep software patched;
- remove environments when no longer required.
A secure production site can still be exposed through an insecure connected web development environment.
49. Review Third-Party Scripts and Integrations
Modern websites commonly load code from external providers.
Examples include:
- analytics;
- advertising;
- chat widgets;
- payment integrations;
- tag managers;
- social embeds;
- A/B testing software;
- marketing automation.
Every external script adds another dependency to your security model.
Regularly ask
- Do we still use this service?
- Is the provider trustworthy?
- What data does it receive?
- Does it need to load on every page?
- Has its account access been reviewed?
- Can its permissions be reduced?
Remove integrations that no longer provide value.
Where appropriate, security mechanisms such as CSP and Subresource Integrity can provide additional protection for certain types of third-party resources.
50. Prepare an Incident Response Plan Before You Need One
Even well-secured websites can experience incidents.
The worst time to decide who should respond to a compromise is after the compromise has already happened.
A basic incident-response process should cover:
- Preserve relevant evidence and logs.
- Confirm and assess the incident.
- Contain unauthorized access.
- Identify the attack vector.
- Remove malicious code, accounts, or persistence mechanisms.
- Patch the underlying weakness.
- Rotate affected passwords, API keys, tokens, and credentials.
- Restore from a known-good backup where appropriate.
- Verify that the website is clean and functioning correctly.
- Review logs for additional affected systems or accounts.
- Notify affected parties or authorities where legally or contractually required.
- Request search-engine or blacklist reviews after remediation, if necessary.
- Increase monitoring after recovery.
- Document what happened.
- Update security controls so the same incident is less likely to recur.
Keep evidence before cleaning
Do not immediately delete every suspicious file or log.
Depending on the seriousness of the incident, logs and compromised files may help determine:
- when the attack occurred;
- how access was obtained;
- which accounts were affected;
- what information may have been accessed;
- whether the attacker established persistence.
For serious breaches, professional incident-response assistance may be appropriate.
How Often Should You Perform Website Security Checks?
Not every security task needs to be performed daily.
A practical schedule looks like this:
| Security Task | Suggested Frequency |
| Uptime monitoring | Continuous |
| Security alerts | Continuous |
| Malware/reputation monitoring | Continuous/daily where appropriate |
| Automated backups | Daily or according to data-change rate |
| Critical security updates | As soon as practical after assessment/testing |
| CMS/plugin/theme review | Weekly or continuously monitored |
| Vulnerability scanning | Monthly and after major changes |
| Administrator account review | Monthly/quarterly |
| Security headers | After configuration/infrastructure changes |
| SSL/TLS | Automated monitoring + periodic review |
| DNS records | Quarterly and after DNS changes |
| Subdomain inventory | Quarterly |
| SPF/DKIM/DMARC | After email/DNS changes + periodic review |
| File permissions | After deployments + periodic review |
| Third-party integrations | Quarterly |
| Backup restoration test | Quarterly or based on business requirements |
| Full security assessment | At least annually and after major architecture changes |
| Incident response plan | At least annually and after significant incidents |
Websites handling payments, healthcare information, financial information, sensitive personal data, or other high-value information may require significantly stronger controls and more frequent assessments.
Recommended Website Security Tools
You do not need one tool that claims to do everything.
Different tools are useful for different security layers.
| Tool | Primary Use |
| Google Safe Browsing | Unsafe website/reputation status |
| VirusTotal | Multi-vendor URL reputation |
| Sucuri SiteCheck | External malware and blacklist scanning |
| SecurityHeaders | HTTP security-header analysis |
| Qualys SSL Labs | Detailed SSL/TLS assessment |
| MXToolbox | DNS, email and infrastructure diagnostics |
| DNSViz | DNSSEC analysis |
| WPScan | WordPress vulnerability assessment |
| OWASP ZAP | Authorized web application security testing |
| Browser DevTools | Headers, cookies and network inspection |
Important: This is intended as a practical website security review aid, not as a substitute for a professional penetration test or security assessment. Always use active scanning tools only on websites you own or have permission to test. A “Pass” result means the item was checked using the selected method; it does not guarantee that no vulnerability exists.
How to Score Your Website Security Audit
For your own internal audit, use four statuses rather than simply Pass/Fail.
| Status | Meaning |
| 🟢 PASS | Verified and appropriately configured |
| 🟡 NEEDS ATTENTION | Improvement or investigation required |
| 🔴 CRITICAL | Significant security problem requiring urgent action |
| ⚪ NOT TESTED | No reliable verification has been performed |
The fourth status is particularly important.
If you have never checked whether .env files are exposed, the correct result is:
⚪ NOT TESTED
not:
🟢 PASS
Absence of evidence is not evidence that the control is correctly configured.
Which Website Security Problems Should You Fix First?
Not every warning has the same severity.
A security-header recommendation should not distract you from an exposed database password.
Critical Priority
Investigate immediately when you discover:
- active malware;
- compromised administrator accounts;
- exposed credentials;
- exposed databases;
- publicly accessible sensitive backups;
- exploitable critical vulnerabilities;
- unauthorized access.
High Priority
Next focus on:
- vulnerable plugins/themes;
- unsupported software;
- missing privileged-account MFA;
- weak API authorization;
- exposed staging systems;
- weak access controls;
- subdomain takeover risks.
Medium Priority
Then address areas such as:
- WAF improvements;
- DNS/email hardening;
- security-header improvements;
- monitoring gaps;
- unnecessary attack surface.
Lower Priority
Finally address lower-risk information disclosure and additional hardening.
Security work should be risk-driven rather than score-driven.
Common Website Security Mistakes to Avoid
A technically strong website can still become vulnerable through basic operational mistakes.
Common examples include:
- assuming HTTPS means the website is completely secure;
- installing unnecessary plugins;
- keeping old administrator accounts;
- reusing passwords;
- delaying security updates;
- leaving backups in public folders;
- forgetting old subdomains;
- exposing staging environments;
- giving everyone administrator access;
- exposing API keys in frontend code;
- running unsupported PHP or other runtimes;
- relying entirely on a WAF;
- never testing backups;
- trusting only one security scanner;
- ignoring security alerts;
- treating every scanner warning as a confirmed vulnerability;
- assuming “no malware detected” means “no vulnerabilities exist.”
Download Site Security Audit PDF File
Can a Website Ever Be 100% Secure?
In practical security, claiming a public website is 100% secure is unrealistic.
Security changes continuously.
A website may be well protected today, but tomorrow:
- a new vulnerability may be disclosed;
- an administrator password may be phished;
- a plugin may become vulnerable;
- a third-party service may be compromised;
- a DNS record may be misconfigured;
- a deployment may accidentally expose a secret.
The objective is therefore not to achieve an imaginary permanent state of perfect security.
The objective is to:
reduce the attack surface, prevent predictable attacks, detect suspicious activity quickly, limit the impact of incidents, and recover safely when something goes wrong.
Final Website Security Checklist (FAQs)
Before considering your security baseline healthy, you should be able to answer “YES” to most applicable questions:
- Is the entire website protected by HTTPS?
- Is the SSL/TLS certificate valid and monitored?
- Does HTTP redirect correctly to HTTPS?
- Is the domain clean in Google Safe Browsing?
- Are malware scans clean?
- Is domain reputation clean across relevant services?
- Is the domain free from relevant blacklist warnings?
- Are HTTP security headers properly configured?
- Is CSP appropriately designed?
- Is HSTS correctly configured?
- Is framing appropriately restricted?
- Is MIME sniffing protection enabled?
- Is Referrer Policy configured?
- Is Permissions Policy appropriate?
- Is the CMS supported and patched?
- Are all plugins reviewed and updated?
- Are themes secure and maintained?
- Has unnecessary software been removed?
- Are administrator privileges restricted?
- Is MFA enabled for privileged accounts?
- Are passwords strong and unique?
- Are repeated login attempts rate-limited?
- Are file permissions appropriately restrictive?
- Are .env files inaccessible?
- Is .git inaccessible?
- Are configuration files protected?
- Are backup archives inaccessible publicly?
- Is directory listing disabled where unnecessary?
- Is the database properly protected?
- Are APIs authenticated and authorized correctly?
- Is CORS configured according to actual requirements?
- Are session cookies appropriately protected?
- Is WAF protection available where appropriate?
- Is DDoS mitigation available?
- Is DNSSEC correctly configured where used?
- Have all subdomains been inventoried?
- Have dangling DNS/subdomain takeover risks been eliminated?
- Is SPF correctly configured?
- Is DKIM working?
- Is DMARC configured and monitored?
- Are backups automated?
- Have backups been successfully restored in testing?
- Are security logs available?
- Is active monitoring enabled?
- Are vulnerability scans performed regularly?
- Are server runtimes supported and patched?
- Is unnecessary version information minimized?
- Are staging/development environments protected?
- Are third-party scripts regularly reviewed?
- Is there a documented incident-response plan?
If several answers are “I don’t know,” those unknowns should become your next security tasks.
Bottom of The Line
Website security is not one setting, one plugin, one firewall, or one scanner score.
It is a collection of layers working together.
HTTPS and TLS protect data in transit. Security headers strengthen browser-side protections. Updates and vulnerability management reduce known weaknesses. MFA and access control protect privileged accounts. WAF and DDoS controls add protection at the traffic layer. DNSSEC, SPF, DKIM, and DMARC help protect domain and email infrastructure. Logging and monitoring help detect suspicious activity. Backups and incident response help the business recover when preventive controls are not enough.
Most importantly, website security requires maintenance.
Software changes. New vulnerabilities appear. Employees and vendors change. New integrations are installed. Old subdomains are forgotten. Configuration mistakes happen.
A useful website security checklist therefore should not be completed once and forgotten. Use these 50 checks as a recurring security process:
Protect → Patch → Restrict → Monitor → Test → Back Up → Recover.
That approach will do far more for real-world website security than chasing a perfect score from any single scanner.
