WebOTG Security Testing Library ● Public reference
W WebOTG
Search
WebOTG
Standards Countries Topics Resources About
WEBOTG SECURITY TESTING PROCEDURE

WebOTG-SM-020 — Missing or Weak HTTP Security Headers

A structured procedure for identifying security-sensitive HTTP response headers that are missing, incorrectly configured, contradictory or weaker than the application's security requirements.

WebOTG ID SM-020 OWASP A02:2025 Type HTTP Security Headers Method Response Analysis Version 1.0
01 / OBJECTIVE

Objective

What are we verifying?

Verify that HTTP responses implement security headers appropriate to the application's architecture, content model and threat environment, and that those headers do not contain configurations that materially weaken browser security controls.

Security headers allow an application to communicate security policies to user agents. Depending on the application, these policies can control content execution, framing, transport security, referrer information, browser capabilities and cross-origin behavior.

Header assessment must be contextual. The absence of a particular header does not automatically constitute a vulnerability. The tester should establish whether the control is applicable and whether its absence or misconfiguration creates a meaningful security weakness.

Do not treat header checklists as automatic findings

A scanner may report a missing header, but the final assessment must consider the application's actual behavior, browser exposure, content types and applicable security requirements.

02 / SCOPE

Scope

Review security-relevant HTTP responses including:

HTML document responses
Authentication and session pages
Sensitive application responses
API responses where relevant
Static resources where policy inheritance or browser behavior makes it relevant
Redirect responses
Error responses
Reverse-proxy or gateway-generated responses
03 / PREREQUISITES

Prerequisites

Authorization Confirm authorization to inspect and test the target web application.
Application architecture Understand whether the application uses HTML, APIs, embedded resources, frames, third-party content or cross-origin integrations.
Browser model Identify whether browser-enforced controls are relevant to the tested application.
Transport Determine whether the application is expected to operate exclusively over HTTPS.
04 / METHODOLOGY

Methodology

Capture representative HTTP responses and evaluate the security headers against the application's documented security requirements.

Review Purpose
Header presence Determine whether applicable security controls are communicated to the browser.
Header value Determine whether the configured policy provides the intended protection.
Scope Determine whether the policy applies to the intended resources and origins.
Conflicts Identify contradictory headers or configurations.
Response consistency Determine whether important responses unexpectedly omit required controls.
05 / PROCEDURE

Test procedure

01
Select representative endpoints Include the homepage, authenticated pages, sensitive functions, API endpoints and relevant error or redirect responses.
02
Capture complete HTTP responses Record response headers and status codes using an authorized browser or HTTP testing tool.
03
Identify applicable security headers Determine which browser security policies are relevant to the application's architecture.
04
Evaluate policy values Review whether configured directives are sufficiently restrictive for the intended application behavior.
05
Check consistency Compare responses from different routes, application states and infrastructure layers.
06
Determine security impact Establish whether the missing or weak policy creates a practical security exposure rather than merely a standards-compliance difference.
06 / HEADER REVIEW

Security header review

CONTENT-SECURITY-POLICY

Controls permitted content sources and browser-executable resources.

Review especially where the application renders user-controlled or third-party content.

STRICT-TRANSPORT-SECURITY

Instructs supporting browsers to use HTTPS for the protected origin.

Review deployment over HTTPS and the intended transport policy.

X-CONTENT-TYPE-OPTIONS

Prevents certain MIME-type sniffing behavior.

Verify the configured value is appropriate for the application.

FRAME-ANCESTOR POLICY

Controls which origins may embed protected resources when supported by the browser.

Review applications where framing could create a meaningful security risk.

REFERRER-POLICY

Controls the amount of referrer information sent with requests.

Consider whether URLs contain sensitive information.

PERMISSIONS-POLICY

Controls access to selected browser features and capabilities.

Configure only the capabilities required by the application.

Example response review

HTTP response EXAMPLE 
HTTP/1.1 200 OK
Content-Type: text/html
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

<html>
    ...
</html>
Evaluate the complete policy, not only header presence

A header can be present and still provide insufficient protection. Review the actual directives, values, scope and interaction with the application's content and trust model.

07 / ASSESSMENT

Assessment

Condition Assessment consideration
Applicable header present and correctly configured Normally passes the header-specific review.
Header absent Determine whether the control is applicable and whether its absence creates meaningful risk.
Header present but weak Assess whether the effective policy can be materially bypassed or weakened.
Header inconsistent Determine whether sensitive routes lack controls that are present elsewhere.
Policy breaks functionality Verify whether the policy can be tightened without unnecessarily weakening security.
08 / EXPECTED RESULT

Expected result

Pass condition

Applicable browser security controls are explicitly configured according to the application's security requirements, with policies sufficiently restrictive to provide their intended protection without unnecessary exceptions.

Security-sensitive responses should not unexpectedly bypass the application's intended browser security policy because of alternate routes, redirects, proxy configurations or application-specific response handlers.

09 / FAILURE CRITERIA

Failure criteria

An applicable browser security control is absent and its absence creates a demonstrated or material risk.
A security header is configured with a value that materially weakens the intended protection.
Sensitive responses unexpectedly omit required security policies.
A security policy contains unnecessary broad exceptions that materially expand the attack surface.
Multiple infrastructure layers produce contradictory or ineffective security policies.
The deployed policy does not match the documented application security requirements.
Example finding SECURITY POLICY WEAKNESS

A sensitive application response does not enforce an applicable browser security policy, while equivalent protected responses do. The inconsistent configuration creates a security boundary that differs from the application's intended policy.

10 / REMEDIATION

Remediation

Define security headers centrally where possible and ensure the resulting policies are applied consistently to all applicable responses.

Recommended approach

  1. Identify which browser security controls are applicable to the application.
  2. Establish a documented baseline for required headers and policy values.
  3. Configure policies at the appropriate application, web-server, gateway or reverse-proxy layer.
  4. Remove unnecessarily broad policy exceptions.
  5. Avoid unsafe or unnecessarily permissive content sources where a stricter policy is feasible.
  6. Ensure HTTPS-only applications enforce the intended transport policy.
  7. Ensure security-sensitive routes inherit or explicitly implement the required controls.
  8. Review third-party integrations before allowing them through browser security policies.
  9. Test policy changes in a controlled environment before production deployment.
  10. Re-test representative responses after every relevant infrastructure or application configuration change.

Example baseline

Illustrative configuration EXAMPLE 
Strict-Transport-Security:
    <organization-defined HTTPS policy>

X-Content-Type-Options:
    nosniff

Referrer-Policy:
    <organization-defined referrer policy>

Content-Security-Policy:
    <application-specific policy>

Permissions-Policy:
    <application-specific capability policy>
Do not copy a generic CSP into production

Content Security Policy is application-specific. A copied policy can either provide insufficient protection or break legitimate functionality. Build the policy from the application's actual resource and trust requirements.

11 / VERIFICATION

Verification

01
Repeat the original test Request the same endpoint and application state used to identify the issue.
02
Capture the complete response Record status code and relevant HTTP security headers.
03
Verify policy values Confirm that the actual directives and values match the intended security baseline.
04
Test protected routes Verify authentication, account-management and other sensitive application routes.
05
Test redirects and errors Verify that relevant redirect and error paths do not unexpectedly remove required controls.
06
Verify application functionality Confirm that legitimate scripts, resources, integrations and browser functionality continue to operate as intended.
PASS

Applicable security headers are present, correctly configured and consistently applied.

FAIL

A material security weakness remains in the deployed header configuration.

NOT TESTED

The applicable security policy could not be adequately evaluated.

12 / EVIDENCE

Evidence requirements

Endpoint and application state tested
HTTP status code
Relevant response headers
Effective policy values
Security impact or demonstrated behavior
Before-remediation evidence
Configuration or deployment evidence
Post-remediation response
Functional verification
Final PASS / FAIL determination
Sanitize evidence

Remove session identifiers, authentication tokens, personal information and other sensitive values before publishing response captures or screenshots.

13 / CLASSIFICATION

Classification

WebOTG procedure WebOTG-SM-020
OWASP category A02:2025 — Security Misconfiguration
Procedure type HTTP security policy and browser security configuration review
Assessment result PASS / FAIL / NOT TESTED
Finding severity Determine from the affected browser security boundary, exploitability, application context and resulting impact.
WebOTG classification notice

WebOTG-SM-020 is a WebOTG-defined verification procedure. The identifier is not an OWASP-defined test identifier.

14 / REFERENCES

References

Source Relevance
OWASP Top 10:2025 — A02 Security Misconfiguration category.
OWASP Web Security Testing Guide Web application testing methodology relevant to security configuration and browser-facing controls.
OWASP Application Security Verification Standard Verification requirements relevant to secure communication and browser security.
HTTP security header specifications Defines the behavior and semantics of individual browser security controls.
Organization security baseline Defines the headers and policy values required for the specific application environment.

WebOTG should maintain official source URLs, source versions and review dates through its content-management system so references can be updated independently of the procedure template.