How to Fix Every Security Audit Finding

The Security Audit looks at your site from the outside, the way a browser or an attacker would, and reports on 23 checks grouped into 9 families. They include HTTP security headers, TLS configuration, cookie flags, mixed content, server fingerprinting, CMS version exposure, mail security DNS records and security.txt.

Most findings are fixed with a few lines of configuration, but where those lines go depends on your setup. This page helps you choose the right layer to fix things in, points you to the guide for your server, control panel or CMS, and suggests an order of work.

By John Carlsson · Updated 28 September 2026 · About 11 minutes to read

📋 Demo 📘 Tutorial 📖 Guide 🔧 Fix

On this page

What the audit looks at
Choosing where to make the fix
The fix guides
Managed and hosted platforms
Mail DNS records and security.txt
Which findings to fix first
Order of work
Questions and answers

What the audit looks at

The checks cover things any visitor's browser can observe, so they are a fair picture of what your site exposes to the world. The table below summarises each area and what a healthy result usually looks like. Exact values depend on your site, so treat these as common starting points rather than rules.

Area	What it protects against	Typical healthy setting
Strict-Transport-Security (HSTS)	Downgrade to unencrypted HTTP	`max-age=31536000; includeSubDomains` once every subdomain supports HTTPS
Content-Security-Policy	Injected scripts and unwanted third-party content	A policy listing the sources your pages really use, introduced in report-only mode first
X-Content-Type-Options	Browsers guessing file types	`nosniff`
Framing protection	Clickjacking	`frame-ancestors` in CSP, or `X-Frame-Options: SAMEORIGIN`
Referrer-Policy	Leaking full URLs to other sites	`strict-origin-when-cross-origin`
Permissions-Policy	Unwanted access to camera, microphone, location	Disable features the site never uses
TLS configuration	Weak or outdated encryption	TLS 1.2 and 1.3 only, with a valid certificate
Cookie flags	Cookie theft and cross-site misuse	`Secure`, `HttpOnly` where scripts do not need the cookie, and a suitable `SameSite` value
Mixed content	Insecure resources on secure pages	Every image, script and style loaded over HTTPS
Fingerprinting and CMS version	Making targeted attacks easier	No server version, no generator tag, no version headers
Mail DNS records	Spoofed email from your domain	SPF, DKIM and a DMARC policy
security.txt	Researchers not knowing how to report issues	A file at `/.well-known/security.txt` with Contact and Expires fields

The full explanation of every check is in the Security Audit Guide, and the example audit report shows what a perfect score looks like.

Choosing where to make the fix

A response header can be added at several points between your application and the visitor. Picking one layer and sticking to it avoids the most common problems: headers that appear twice, headers that vanish on some pages, and changes that seem to do nothing because another layer overrides them.

Edge or CDN, such as Cloudflare. Changes apply in front of any origin and are easy to roll back. Good when you cannot touch the server.
Web server, such as nginx or Apache. The most reliable place for headers and TLS settings, and applies to every response, including images and error pages if configured correctly.
Control panel, such as Plesk, cPanel or DirectAdmin. A friendly front end to the web server configuration, with its own quirks about where directives are stored.
Application or CMS, such as WordPress or Drupal. Useful when hosting locks you out of server settings, but usually only covers pages the CMS generates, not static files.

Traps that catch experienced admins

In nginx, an add_header inside a location block replaces every header inherited from the server block, so headers can silently disappear on some paths.
Without the always parameter in nginx, or Header always set in Apache, headers may be missing from error responses.
Setting the same header at the CDN and the origin can produce duplicate or conflicting values.
A strict Content-Security-Policy applied straight to production can break analytics, payment forms and embedded media. Use Content-Security-Policy-Report-Only first and review what it would block.
Adding a domain to the HSTS preload list is hard to undo. Only do it once you are certain every subdomain will always use HTTPS.

The fix guides

Every guide maps back to the same set of checks. Choose one by how you like to learn, then by where your site is configured.

By skill level

The Beginner Guide gives copy-and-paste fixes for the most common failures with no assumed command-line knowledge, plus what to ask your host when you cannot make a change yourself. The Expert Guide is a dense reference for sysadmins, covering edge cases, trade-offs, header inheritance and patterns that look right but fail in production.

By server or control panel

Plesk covers panel.ini, additional nginx directives, removing the X-Powered-By PleskLin header and securing every domain on a shared install. cPanel covers .htaccess header rules, ModSecurity tuning and Apache or LiteSpeed settings. DirectAdmin covers custom configuration at user and server level. Bare nginx covers add_header placement, server_tokens and ssl_protocols. Bare Apache covers mod_headers, ServerTokens, ServerSignature and ETag fingerprinting. Cloudflare covers Transform Rules and response header changes at the edge, and how they interact with the origin.

By CMS or application

WordPress covers removing the generator tag, adding headers in code or with a plugin, and wp-config.php hardening. Joomla covers the HTTP Headers plugin and version exposure in Joomla 4 and 5. Drupal covers the Security Kit module and removing X-Generator headers in Drupal 10 and 11. Ghost covers running nginx in front of Ghost and the limits of managed Ghost hosting. Forum software covers phpBB, Discourse, Flarum and vBulletin, including cookie security for logged-in members and a CSP that does not break embeds.

Managed and hosted platforms

If your site runs on Shopify, Wix, Squarespace, Webflow, Substack, Medium, Blogger, BigCommerce or a managed WordPress host such as WP Engine or Kinsta, much of what the audit checks is controlled by the platform, not by you. Security headers, TLS protocols, mixed content protection and server fingerprinting are usually handled for you, and you normally cannot change them.

That does not mean there is nothing to do. On most managed platforms you can still control:

Your domain's mail records. SPF, DKIM and DMARC live in DNS, which you manage wherever your domain is registered or hosted, regardless of the website platform.
Cookies from your own code and add-ons. Custom scripts, apps and third-party integrations may set cookies without secure flags.
Mixed content you introduced. An image or embed pasted with an http:// address can still cause warnings.
security.txt, where the platform lets you publish files under /.well-known/.

If your score is below 100 on a managed platform, the remaining finding is often a platform header such as its own X-Powered-By branding. You cannot remove it, so it is reasonable to accept it as a platform finding and focus on the items you control.

💡 Ask your platform's support team for their security documentation. Most publish what they set by default, which helps you explain any remaining findings to clients or auditors.

Mail DNS records and security.txt

These two checks sit outside the web server entirely, which is why they are often forgotten even on well-configured sites.

SPF, DKIM and DMARC

SPF lists the services allowed to send email for your domain in a single TXT record. DKIM adds a cryptographic signature to messages, using a key published in DNS by your email provider. DMARC tells receiving servers what to do when a message fails those checks and where to send reports. Together they make it much harder for someone to send convincing fake email in your name, and large mailbox providers such as Gmail and Yahoo now expect them from bulk senders.

List every service that sends email as your domain: your mailbox provider, newsletter tool, shop platform, CRM and helpdesk.
Make sure there is only one SPF record and that it includes all of them. SPF evaluation fails if it needs more than ten DNS lookups.
Turn on DKIM in each sending service and publish the records it gives you.
Start DMARC with p=none and a reporting address, review the reports, then move to quarantine and eventually reject once legitimate mail passes.

security.txt

Defined in RFC 9116, security.txt is a small text file at /.well-known/security.txt that tells security researchers how to report a problem. The Contact and Expires fields are required. Set a reminder to update the expiry date before it passes, because an expired file is reported as a finding.

Which findings to fix first

Not every check carries the same risk, and not every one matters for every site. A brochure site with no logins has different priorities from a shop or a membership forum.

TLS problems and missing HTTPS redirects. Everything else depends on the connection being encrypted.
Cookie flags on login and session cookies. Especially important for shops, forums and any site with accounts.
Mixed content. Browsers may block insecure resources, breaking the page as well as weakening it.
Core headers: HSTS, X-Content-Type-Options, framing protection and Referrer-Policy. Low risk to add and widely supported.
Mail DNS records. Protects your domain's reputation and your customers from spoofed messages.
Fingerprinting and version exposure. Hiding versions does not fix vulnerabilities, but it removes an easy signal for automated attacks. Keeping software updated matters more.
Content-Security-Policy, Permissions-Policy and security.txt. Valuable, but CSP in particular needs care and testing.

⚠️ Always back up configuration files before editing them, and test in a staging copy or on a single domain first. A syntax error in a web server config can take the whole site offline.

Order of work

Run the Security Audit on your domain and note which checks fail.
Work out which layer controls your headers: CDN, web server, control panel or CMS. Pick one layer for headers.
Open the guide for that layer from the list above, or the Beginner Guide if you are unsure.
Fix TLS and HTTPS redirects, then cookie flags and mixed content.
Add the core security headers, then re-run the audit to confirm they appear on every page type, including errors.
Set up SPF, DKIM and DMARC for every service that sends email for your domain.
Remove version information and generator tags.
Introduce a Content-Security-Policy in report-only mode, adjust it, then enforce it.
Publish security.txt and diarise the expiry date.
Re-run the audit after every hosting, plugin or CDN change.

New to all of this? The beginner tutorial explains the basics before you start editing anything.

Questions and answers

1. Which security headers does every website need?

Most sites benefit from Strict-Transport-Security, X-Content-Type-Options set to nosniff, framing protection through CSP frame-ancestors or X-Frame-Options, and a Referrer-Policy such as strict-origin-when-cross-origin. A Content-Security-Policy and Permissions-Policy add further protection but need more tailoring to your site. The exact set depends on what your site does, so use the audit results to see which are missing and add them in whichever layer controls your responses, then run the audit again to confirm them.

2. Why do my headers show on some pages but not others?

This usually means the headers are set in only one part of the configuration. In nginx, an add_header directive inside a location block replaces the headers from the server block, so pages served by that location lose them. Headers set by a CMS may not apply to static files, and headers without the always option may be missing from error pages. Set headers in one consistent place and re-test several page types, including an error page and an image.

3. Will a Content-Security-Policy break my site?

It can if you apply a strict policy without testing, because it blocks any script, style, font or frame from sources the policy does not list. Analytics, payment forms, chat widgets and embedded videos are common casualties. Start with the Content-Security-Policy-Report-Only header, which reports what would be blocked without blocking it. Review the reports, adjust the policy until legitimate resources are allowed, and only then switch to the enforcing header.

4. Should I submit my site to the HSTS preload list?

Only if you are sure every current and future subdomain will always support HTTPS. Preloading builds your domain into major browsers so they never try an unencrypted connection, which is strong protection, but removal takes a long time to reach all users. A normal HSTS header with a long max-age already protects returning visitors. Many sites never preload, and that is a perfectly reasonable choice for a small business website.

5. Does hiding my server version make my site secure?

No. Removing version numbers and generator tags makes it harder for automated tools to match your site to a known vulnerability, which is worthwhile, but the vulnerability is still there if the software is out of date. The real protection is keeping the server, CMS, plugins and themes updated. Treat fingerprint removal as a small extra layer on top of regular updates and good passwords, never as a substitute for them.

6. I use Shopify or Wix. Why is my security score not 100?

On managed platforms the provider controls most server settings, including some headers that identify the platform. You usually cannot remove these, so a score below 100 often reflects the platform rather than anything you did wrong. Focus on what you can control: your domain mail records, cookies set by your own scripts and apps, any insecure links you added to pages, and security.txt if the platform lets you publish it.

7. What is a DMARC policy and which one should I use?

DMARC is a DNS record that tells receiving mail servers how to treat messages that fail SPF and DKIM checks, and where to send reports about them. Start with p=none and a reporting address so you can see which services send mail as your domain without affecting delivery. Once all legitimate mail passes, move to p=quarantine, then p=reject, which gives the strongest protection against spoofing. Review the reports at each step before tightening the policy further.

Run the audit before you start

The Security Audit checks headers, TLS, cookie flags, mixed content, fingerprinting, CMS version exposure, mail DNS records and security.txt, so you can see exactly which fixes your domain needs before changing anything.

Run the Security Audit →