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

WebOTG-SM-014 — Missing Security Headers

A structured procedure for identifying missing, ineffective or incorrectly configured HTTP security headers and verifying that browser security controls are appropriately applied to the application.

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

Objective

What are we verifying?

Verify that HTTP responses implement appropriate browser security controls and do not rely on insecure or unnecessary response-header configurations.

Modern browsers provide security mechanisms that can be configured through HTTP response headers. These controls can reduce risks associated with content injection, framing, MIME-type confusion, insecure transport and other browser-side attack conditions.

This procedure evaluates the headers actually delivered to clients rather than merely checking whether a header exists in server configuration.

Header presence does not automatically mean secure configuration

A header can be present while still being ineffective, overly permissive, contradictory or incorrectly scoped. Assessment must consider the actual policy value and application requirements.

02 / SCOPE

Scope

Review security headers across:

Public HTML responses
Authenticated application pages
Administrative interfaces
REST and JSON API responses
Static resources where applicable
Redirect responses
Error responses
Reverse proxy / CDN responses
HTTPS endpoints
03 / PREREQUISITES

Prerequisites

Authorization Confirm authorization to assess the application's HTTP responses and security configuration.
HTTPS endpoint Identify the canonical HTTPS endpoint and any HTTP-to-HTTPS redirect path.
Application architecture Identify web servers, reverse proxies, CDNs and other components capable of modifying response headers.
Browser requirements Understand application dependencies, supported browsers and legitimate cross-origin requirements before evaluating restrictive policies.
04 / METHODOLOGY

Methodology

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

Method Purpose
Response inspection Determine which security headers are actually delivered to clients.
Policy-value review Determine whether configured values provide meaningful protection.
Endpoint comparison Identify inconsistent security-header configurations between application paths.
HTTPS behavior review Verify transport-related browser controls and redirect behavior.
Browser validation Confirm that applicable browser policies behave as intended without breaking legitimate functionality.
05 / PROCEDURE

Test procedure

01
Identify representative endpoints Select public, authenticated, administrative, API and error endpoints where applicable.
02
Capture HTTP responses Inspect the complete response headers delivered by the deployed application.
03
Identify security controls Record applicable controls such as CSP, HSTS, frame restrictions, MIME-type protection and referrer-policy configuration.
04
Evaluate policy values Determine whether each policy is appropriately restrictive for the application's actual architecture and requirements.
05
Compare endpoints Identify security-sensitive endpoints where headers are missing or unexpectedly different from the application's baseline.
06
Validate browser behavior Where applicable, verify that the effective policies are recognized by supported browsers and provide the intended security behavior.
06 / HEADER CONTROLS

Header controls

Control Review focus
Content-Security-Policy Determine whether the policy meaningfully restricts content sources and reduces relevant browser-side injection risks.
Strict-Transport-Security On HTTPS sites, determine whether HSTS is appropriately configured for the application's deployment model.
X-Content-Type-Options Verify appropriate MIME-sniffing protection for responses where relevant.
Referrer-Policy Verify that referrer information is restricted according to application privacy and security requirements.
Frame protection Evaluate CSP frame-ancestors and/or other applicable controls against the application's legitimate framing requirements.
Permissions-Policy Where applicable, review whether unnecessary browser capabilities are restricted.

Example response

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

Content-Security-Policy: default-src 'self'; object-src 'none'
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Do not copy a generic header template blindly

Security policies must match the application's architecture. For example, a CSP that blocks legitimate scripts, frames or connections is not automatically a successful security configuration. Test the policy against actual application behavior.

07 / ASSESSMENT

Assessment

Condition Assessment consideration
Header present and effective Control may be considered appropriately implemented after validating its policy value and application compatibility.
Header absent Determine whether the missing control creates a material security gap for the application.
Weak policy Determine whether the configuration provides substantially less protection than intended.
Inconsistent policy Investigate security-sensitive endpoints that do not receive the expected baseline.
Legacy header only Determine whether modern equivalent controls should also be implemented.
08 / EXPECTED RESULT

Expected result

Pass condition

Applicable browser security controls are delivered consistently to relevant application responses and are configured according to documented security requirements without unnecessarily disrupting legitimate application functionality.

The final assessment should consider the application's architecture rather than treating the absence of a particular header as an automatic vulnerability.

09 / FAILURE CRITERIA

Failure criteria

A required security control is absent from relevant production responses.
A security policy is configured so weakly that it provides little or no intended protection.
Security-sensitive endpoints unexpectedly omit the application's required security baseline.
HTTPS deployments lack appropriate transport security configuration where required by policy.
Browser capabilities or framing behavior are unnecessarily exposed contrary to documented security requirements.
Proxy, CDN or application-layer configuration unintentionally removes required security headers.
Example finding HTTP SECURITY CONFIGURATION

A production HTTPS application does not deliver the organization's required transport-security policy to its primary web responses. The missing configuration reduces the browser-enforced transport security expected for the application.

10 / REMEDIATION

Remediation

Establish a centralized HTTP security-header baseline and apply it consistently through the appropriate application, web-server, reverse-proxy or CDN layer.

Recommended approach

  1. Define the organization's required security-header baseline.
  2. Identify which headers are applicable to the application's architecture.
  3. Configure policies at the appropriate deployment layer.
  4. Avoid duplicate or contradictory header values across application and proxy layers.
  5. Configure CSP according to actual application dependencies rather than copying an unrelated policy.
  6. Configure transport security appropriately for HTTPS deployments.
  7. Configure MIME-type, referrer and framing protections according to application requirements.
  8. Restrict unnecessary browser capabilities where appropriate.
  9. Test security-header behavior across normal, authenticated and error responses.
  10. Include the configuration in deployment controls so it cannot silently disappear during infrastructure changes.

Example baseline

Illustrative baseline EXAMPLE 
Content-Security-Policy:
    default-src 'self';
    object-src 'none'

Strict-Transport-Security:
    max-age=31536000

X-Content-Type-Options:
    nosniff

Referrer-Policy:
    strict-origin-when-cross-origin

Permissions-Policy:
    [define only required browser capabilities]
Policy values must be reviewed, not blindly copied

The values above are illustrative. WebOTG should document the actual recommended policy separately from this verification procedure and require organizations to adapt policies to their application architecture and security requirements.

11 / VERIFICATION

Verification

01
Capture the response Request representative production or staging endpoints and record the returned headers.
02
Compare against baseline Confirm that required security headers are present with the expected policy values.
03
Check endpoint consistency Compare public, authenticated, administrative and relevant error responses.
04
Validate browser enforcement Confirm applicable policies are recognized and enforced by supported browsers.
05
Test application functionality Verify that required scripts, frames, APIs, authentication flows and legitimate integrations continue to function.
06
Verify deployment persistence Confirm that headers remain present after deployment, proxy changes, cache changes and infrastructure updates.
PASS

Applicable security-header controls are present, effective and consistently delivered.

FAIL

A material security-header configuration gap remains in the deployed application.

NOT TESTED

The effective configuration or browser enforcement could not be adequately verified.

12 / EVIDENCE

Evidence requirements

Tested endpoint
Complete relevant HTTP response headers
Security-header baseline
Policy-value assessment
Browser validation evidence where applicable
Before-remediation response
Post-remediation response
Functional compatibility result
Final PASS / FAIL determination
Sanitize evidence

Remove cookies, authorization tokens, API keys, internal hostnames and other sensitive values before storing or sharing HTTP captures.

13 / CLASSIFICATION

Classification

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

WebOTG-SM-014 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 Application Security Verification Standard Verification requirements relevant to secure communication, browser controls and application configuration.
HTTP security-header specifications Authoritative technical definitions and behavior of applicable HTTP security mechanisms.
Application security baseline Organization-specific requirements for response-header configuration.

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.