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

WebOTG-SM-006 — HTTP Security Headers

A structured procedure for reviewing HTTP response headers that provide browser-side security controls and for identifying missing, weak or incorrectly configured security policies.

WebOTG ID SM-006 OWASP A02:2025 Type Security Configuration Method HTTP Response Review Version 1.0
01 / OBJECTIVE

Objective

What are we verifying?

Verify that appropriate HTTP security controls are configured for the application and that security headers are present, correctly scoped and compatible with the application's intended behavior.

HTTP response headers can instruct browsers how to handle content, framing, referrer information, transport security and other security-sensitive behavior.

Missing or incorrectly configured headers may weaken browser-side protections. However, the absence of a particular header is not automatically a vulnerability. The assessment must consider application architecture, browser behavior and the security requirement being addressed.

Do not apply headers blindly

Security headers can break legitimate application functionality when configured incorrectly. Validate the policy against the application's actual resource loading, framing, authentication and navigation requirements.

02 / SCOPE

Scope

Review security-relevant HTTP responses including:

Public application pages
Authentication and session-related pages
Administrative interfaces
API responses where browser security policy applies
Static resources and content delivery paths
Redirect responses
Error responses
03 / PREREQUISITES

Prerequisites

Authorization Confirm authorization to assess the application and its HTTP configuration.
Application map Identify representative public, authenticated and administrative pages.
Architecture Identify relevant web servers, reverse proxies, CDNs and security gateways.
Browser requirements Understand legitimate browser-side functionality and third-party resources.
04 / METHODOLOGY

Methodology

Review the actual HTTP response generated by the production-facing application rather than relying exclusively on server configuration.

Method Purpose
HTTP inspection Determine which security headers are returned to clients.
Policy review Evaluate whether header values provide the intended security control.
Cross-path comparison Detect inconsistent header application between pages or response types.
Browser validation Confirm that the policy is enforced without breaking required functionality.
05 / PROCEDURE

Test procedure

01
Select representative URLs Select public pages, authenticated pages, administrative pages and relevant response types.
02
Capture HTTP responses Record response headers from the production-facing endpoint, including redirects where relevant.
03
Identify security headers Review the response for applicable security controls and examine their exact values.
04
Evaluate policy strength Determine whether the configured values actually provide the intended protection.
05
Compare application paths Check whether security headers are consistently applied across relevant application responses.
06
Validate functionality Confirm that legitimate scripts, styles, frames, resources and navigation continue to work.
06 / HEADER REVIEW

Security header review

Strict-Transport-Security

Review whether HTTPS-only access is enforced appropriately for the application and domain.

Content-Security-Policy

Review whether content sources are restricted according to the application's security model.

X-Content-Type-Options

Review whether browsers are instructed not to perform unintended MIME-type sniffing.

Referrer-Policy

Review whether referrer information is appropriately restricted.

Permissions-Policy

Review whether unnecessary browser capabilities are appropriately restricted.

Framing controls

Review CSP frame-ancestors and other applicable framing protections where clickjacking risk is relevant.

Example response

HTTP response headers EXAMPLE 
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

Strict-Transport-Security: max-age=31536000
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=()
Header presence is not sufficient

A header can be present while its value is ineffective, excessively permissive or incompatible with the intended security requirement. Always assess both presence and configuration.

07 / ASSESSMENT

Assessment

Condition Assessment consideration
Header present and appropriately configured Generally meets the relevant configuration objective.
Header missing Determine whether the missing control represents a meaningful security weakness.
Header present but overly permissive Assess the actual protection provided by the policy.
Inconsistent header configuration Investigate whether sensitive or security-critical paths are excluded.
Header breaks legitimate functionality Policy requires correction rather than simply being considered secure.
08 / EXPECTED RESULT

Expected result

Pass condition

Applicable HTTP security controls are intentionally configured, their policies provide the required protection, and the controls are consistently applied to relevant application responses without disrupting legitimate functionality.

Security header requirements should be based on the application's threat model and security architecture, rather than on simply maximizing the number of headers.

09 / FAILURE CRITERIA

Failure criteria

A required security policy is absent and the omission creates a meaningful security weakness.
A security header is configured with an ineffective or unnecessarily permissive value.
Security headers are missing from security-sensitive application paths.
HTTPS enforcement is incorrectly configured where strict transport protection is required.
Framing protections do not match the application's intended trust boundaries.
Security policy changes have created an unsafe workaround or inconsistent configuration.
Example finding REVIEW REQUIRED

The application's public-facing responses do not provide the browser security control required by the application's security architecture, leaving the affected browser behavior insufficiently restricted.

10 / REMEDIATION

Remediation

Configure applicable security headers at the most reliable enforcement layer available, such as the application, reverse proxy or web server.

Recommended approach

  1. Define the browser security requirements for the application.
  2. Identify which policies are applicable to each application type and response.
  3. Configure security headers centrally where practical.
  4. Avoid unnecessarily broad source, framing or capability permissions.
  5. Test the policy against all legitimate third-party resources and application functionality.
  6. Apply HTTPS transport protection consistently where appropriate.
  7. Review redirects and error responses for inconsistent security policies.
  8. Document exceptions and their business justification.

Example server configuration

Illustrative configuration EXAMPLE 
Strict-Transport-Security:
    max-age=31536000

X-Content-Type-Options:
    nosniff

Referrer-Policy:
    strict-origin-when-cross-origin
Policy values must be application-specific

Do not copy a Content-Security-Policy or other restrictive policy into production without testing. A policy that is technically strict but incorrectly designed can break application functionality or encourage unsafe exceptions.

11 / VERIFICATION

Verification

01
Repeat the original HTTP requests Capture the same representative responses used during the initial assessment.
02
Confirm header presence Verify that required headers are returned by the production-facing endpoint.
03
Confirm header values Verify that the configured policies match the documented security requirements.
04
Test application functionality Confirm that legitimate scripts, styles, embedded resources, navigation and integrations continue to operate.
05
Check configuration consistency Verify that relevant pages, redirects and application paths receive the intended policies.
PASS

Required policies are correctly configured, effective and compatible with application behavior.

FAIL

Required security controls remain absent, ineffective or incorrectly configured.

NOT TESTED

The relevant policy or application behavior could not be adequately verified.

12 / EVIDENCE

Evidence requirements

Application and environment tested
Representative URLs tested
HTTP response headers before remediation
Security policy assessment
Configuration change evidence
HTTP response headers after remediation
Functional verification results
Documented exceptions, if applicable
Sanitize published evidence

Remove cookies, authorization headers, access tokens, internal hostnames and other sensitive information before publishing HTTP captures or screenshots.

13 / CLASSIFICATION

Classification

WebOTG procedure WebOTG-SM-006
OWASP category A02:2025 — Security Misconfiguration
Procedure type HTTP security policy review
Assessment result PASS / FAIL / NOT TESTED
Finding severity Determine from the missing or weakened control, exploitability and resulting security impact.
WebOTG classification notice

WebOTG-SM-006 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 security testing methodology.
OWASP Secure Headers Project Security header guidance and browser security considerations.
MDN Web Docs Browser behavior and HTTP security header reference.
IETF HTTP specifications Standards and normative requirements for relevant HTTP mechanisms.

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.