HTTP HEADERS
What do web security headers change?
Security headers look like small lines of text, but they change how a browser treats a page. The correct value depends on the application, so a header should be understood before it is copied into a server configuration for the sake of a score.
HSTS: making HTTPS the remembered default
Strict-Transport-Security tells supporting browsers to use HTTPS for the host for a defined period. The normal HTTP-to-HTTPS redirect still matters; HSTS helps future visits avoid beginning with an insecure request.
Before using includeSubDomains or preload, make sure every affected subdomain is ready for HTTPS. A long-lived policy can make an old or overlooked subdomain difficult to reach.
Content-Security-Policy: defining allowed resources
CSP limits where scripts, styles, images, frames, and network connections may come from. A useful policy describes resources the application actually needs and avoids broad wildcard permissions that cancel much of the intended protection.
After adding or tightening a policy, inspect browser violations. Deliberately allowing a required CAPTCHA, analytics, or advertising domain is different from opening every source just to make an error disappear.
X-Content-Type-Options: limiting MIME guessing
X-Content-Type-Options: nosniff limits browser MIME sniffing for relevant resources. It is a simple control, but it does not replace correct Content-Type headers.
Check that static assets and API responses return the MIME types they actually contain. A wrong Content-Type can still break resources even when nosniff is present.
Referrer-Policy: controlling how much URL context leaves the page
Referrer-Policy controls how much address information is sent in the Referer header when a user moves to another resource. strict-origin-when-cross-origin is a common balance that keeps more context on the same origin and sends less detail across origins.
Sensitive information should still not be placed in query parameters. A referrer policy is not a safe-storage mechanism for secrets in URLs.
Permissions-Policy: closing browser capabilities you do not use
Permissions-Policy can limit features such as camera, microphone, location, and payment APIs. Explicitly disabling a feature that the site never uses can reduce accidental permission prompts and unnecessary browser surface.
If the product later adds video calls, maps, or a payment flow, the policy should be reviewed with that feature. There is no single permanent value that fits every site.
Framing protection and CSP frame-ancestors
If a page never needs to be embedded by another site, CSP frame-ancestors can limit framing and reduce clickjacking exposure. X-Frame-Options is an older control that is still seen in many deployments.
Dashboards, payment flows, or partner integrations may have a legitimate embedding requirement. Define the allowed origins around the real use case rather than applying DENY blindly.
How to validate a header change
Do not stop at the source file. Request the production URL after the change, inspect the final response after CDN and reverse-proxy layers, and confirm that the browser console has not gained new first-party errors.
MaxAuditor Pro summarizes that final public response. If a finding remains, review cache state, the selected hostname, deployment status, and any proxy that can rewrite headers.