Security Headers: Small Settings Worth Checking

The OWASP HTTP Headers Cheat Sheet explains useful response headers and their limitations. A checklist can identify settings worth investigating, but a score is not a complete assessment of the website or its customer-data handling.

Ask your developer which headers the site currently sends and which risks a proposed change addresses. Avoid copying a block of settings from another website without checking your own forms, payments, embedded media and business integrations.

A policy that is too broad may offer little benefit. A policy that is too strict can stop checkout, analytics or an accessibility tool from working. The OWASP CSP guidance describes implementation options, including report-only testing.

Report-only mode can help a developer observe what a proposed policy would block before enforcement. Reports may contain information about visited pages, so their handling and retention need consideration too. Do not turn them into a public troubleshooting feed.

Content-type handling is another check. The browser should receive the correct content type, and a developer can consider settings that prevent inappropriate guessing. These controls belong alongside correct server behaviour, not instead of it.

Avoid assuming every old security header is useful. OWASP cautions about obsolete approaches, including legacy browser XSS filters. Ask for a maintained explanation rather than a longer list simply to improve a scanner score.

Before enforcing HSTS, check HTTPS works consistently and understand the impact on subdomains. A long policy or preload choice can be difficult to reverse quickly. Your developer should explain these implications and test the relevant hostnames rather than applying the strongest-looking value by default.

After deployment, check the actual responses from the public site, including pages served through a CDN. Different page types can receive different headers. Confirm a rollback process and review whether an external provider has changed its requirements.

For a fictional appointment business, a strict script policy might block an embedded booking service. A developer identifies that dependency in testing and agrees an appropriately narrow policy. This is an illustrative decision, not a client case study.

Agree the pages, integrations, tests and recovery steps in writing. If you require assurance for a regulated or sensitive application, specify that separately. The useful outcome is an explained, tested configuration—not a claim that a scanner score means your business is protected from every attack.

No. It measures a limited set of response settings, not every application risk, access rule or operational process.

Yes. A policy can block scripts or connections a checkout needs, so test the actual payment journey before enforcement.

Assess the real HTTPS configuration and dependencies first. Policies covering subdomains require particular care.