HTTP security headers
Verify browser security policy on delivered responses, choosing appropriate headers and testing CDN, error-page, and content-type behavior.
What it means
HTTP security headers communicate browser protection rules through server responses. Different headers address different risks, such as framing, MIME interpretation, referrer disclosure, and transport policy. Their effect depends on the response type and the browser processing the response.
A practical example
A team audits the headers returned by its public pages, error pages, and API endpoints. It discovers that an edge cache serves some documents without the framing policy configured on the application server, creating inconsistent protection.
What to check
Inspect delivered responses rather than configuration files alone. Verify header values at the CDN and application layers, document intended behavior, and test after changes to routing or caching.
A common pitfall
Adding every historical security header is not automatically helpful. Some are obsolete or inappropriate for particular content; choose controls based on current browser guidance and the application.
Think it through
Where should you verify a policy if a CDN fronts the application?
Answer: On the response the user receives, because intermediaries can add, remove, or cache headers.
Choose a policy for the risk
Imagine a fictional academy embeds a public video player but wants to prevent its grading dashboard from being framed by unrelated sites. Those pages have different embedding requirements. A useful header review starts with intended behavior rather than adding an identical historical header list everywhere.
Headers can influence framing, transport, content interpretation, referrer disclosure, and resource loading. They have different syntax and browser behavior. One present header does not establish that the other risks are addressed.
The response is the observable result
Suppose an application sends a policy but the CDN serves a cached document without it. Reviewing the application setting alone misses what the learner receives. Error pages and alternate routes can also have different response behavior.
Inspect representative delivered responses through the actual public path. Record the URL, response type, relevant header values, and the behavior being tested. A report should explain what the policy accomplishes rather than simply counting headers.
Compatibility belongs in the rollout
A restrictive policy can block legitimate scripts, embeds, or other application behavior if deployed without understanding dependencies. Where a policy supports a reporting or staged mechanism, use it appropriately and investigate the results before broad enforcement.
The academy's video page might need an explicit allowed embedding relationship while the grading page remains restrictive. Document the exception and its owner instead of weakening every page to fix one feature.
For an exercise, choose a public content page, a private dashboard, and an error response in a lab you own. Write the desired framing and transport behavior for each and compare it with the delivered headers. Test the behavior in a supporting browser without treating absent console errors as complete proof. Useful verification connects the response value to the expected user-agent decision and checks the important alternate paths.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: HTTP Headers