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

WebOTG-SM-025 — Missing or Misconfigured Security Headers

A structured procedure for reviewing HTTP response security headers and determining whether missing, weak or incorrectly configured browser security controls expose the application to avoidable security risk.

WebOTG ID SM-025 OWASP A02:2025 Type HTTP Configuration Review Method Manual Verification Version 1.0
01 / OBJECTIVE

Objective

What are we verifying?

Verify that applicable HTTP security headers are present, correctly configured and consistent with the application's security requirements and deployment architecture.

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

The assessment should not become a checklist exercise where every possible header is blindly added. Each control must be evaluated against the application's functionality, browser requirements, deployment architecture and compatibility constraints.

02 / SCOPE

Scope

Review applicable responses from:

Public HTML pages
Authenticated application pages
API responses
Static resources where applicable
Error responses
Redirect responses
Reverse proxy and CDN responses
Production and approved staging environments
03 / PREREQUISITES

Prerequisites

Authorization Confirm authorization to inspect HTTP responses and test the application.
Application architecture Understand whether headers are generated by the application, web server, reverse proxy, CDN or another infrastructure layer.
Browser requirements Understand browser-facing functionality such as frames, scripts, workers, cross-origin resources and embedded content.
Baseline Obtain the organization's approved security-header baseline where one exists.
04 / METHODOLOGY

Methodology

Capture representative HTTP responses and inspect the security-relevant response headers. Determine whether each applicable control is absent, present but weak, incorrectly scoped or appropriately configured.

Review Purpose
Header presence Determine whether applicable controls are actually delivered to clients.
Header value Determine whether the configured policy provides meaningful protection.
Scope Determine whether the policy applies to the intended resources and contexts.
Consistency Compare normal, authenticated, error and redirected responses where relevant.
Application compatibility Determine whether the policy is compatible with legitimate application functionality.
05 / PROCEDURE

Test procedure

01
Select representative endpoints Select public pages, authenticated pages, APIs and other response types that represent the application's production behavior.
02
Capture HTTP responses Record the complete response headers using an authorized HTTP client, browser developer tools or approved testing tooling.
03
Identify applicable security controls Determine which security headers and policies are relevant to the application's architecture and functionality.
04
Evaluate configuration Review each applicable header for missing, weak, overly permissive or contradictory configuration.
05
Review response variations Compare representative response classes to identify security policies that disappear or change unexpectedly.
06
Determine security impact Establish whether the configuration creates a meaningful reduction in the application's intended browser security controls.
06 / HEADERS TO REVIEW

Security headers and policies

CONTENT-SECURITY-POLICY

Controls permitted content sources and browser execution behavior. Review especially for unnecessarily permissive script and object policies.

Content-Security-Policy
STRICT-TRANSPORT-SECURITY

Instructs supporting browsers to use HTTPS for the protected host according to the configured policy.

Strict-Transport-Security
X-CONTENT-TYPE-OPTIONS

Prevents browsers from MIME-sniffing responses where the policy is applicable.

X-Content-Type-Options: nosniff
FRAME-ANCESTORS

Where applicable, use CSP framing policy to define which origins may embed the resource.

Content-Security-Policy
REFERRER-POLICY

Controls the amount of referrer information browsers send with subsequent requests.

Referrer-Policy
PERMISSIONS-POLICY

Restricts selected browser capabilities where the application has no legitimate need for them.

Permissions-Policy
CROSS-ORIGIN POLICIES

Review applicable cross-origin isolation and resource policies according to application requirements.

COOP / COEP / CORP
LEGACY / OBSOLETE CONTROLS

Identify obsolete headers and directives that may create a false impression of protection.

Review current browser support
Do not blindly copy a security-header template

A policy that is secure in one application can break another. For example, a strict content policy may conflict with legitimate third-party resources, embedded services or application architecture. Security headers must therefore be designed, tested and verified against actual requirements.

Example response

HTTP response headers EXAMPLE 
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Security-Policy: default-src 'self'
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=()
07 / ASSESSMENT

Assessment

Condition Assessment consideration
Header present and appropriate Generally acceptable for the applicable security requirement.
Header missing Determine whether the missing control is applicable and whether its absence creates meaningful security exposure.
Weak policy Determine whether the configured policy provides materially less protection than the application's security requirements.
Overly permissive policy Assess whether unnecessary origins, browser capabilities or content sources are allowed.
Inconsistent configuration Determine whether sensitive or important response types receive weaker controls than the rest of the application.
Header deliberately omitted Validate the documented architectural reason before reporting the omission.
08 / EXPECTED RESULT

Expected result

Pass condition

Applicable browser security controls are implemented through appropriate HTTP response policies, with configurations that are sufficiently restrictive for the application's threat model and compatible with legitimate functionality.

Security policies should be applied consistently across relevant production response paths and should not rely on obsolete controls as the primary protection mechanism.

09 / FAILURE CRITERIA

Failure criteria

An applicable security policy is absent without a documented architectural reason.
A browser security policy is configured more permissively than required.
Content Security Policy allows unnecessary or excessively broad content sources.
HTTPS enforcement policy is absent where the application requires persistent HTTPS protection.
Important response paths return materially weaker security policies than the normal application path.
The deployment relies on obsolete browser controls while failing to implement current applicable controls.
Example finding WEAK BROWSER POLICY

A production application delivers an unnecessarily permissive Content Security Policy that allows content from broad external sources. The configured policy is not aligned with the application's documented resource requirements and provides weaker browser-side containment than necessary.

10 / REMEDIATION

Remediation

Establish an application-specific security-header baseline and implement it at the most appropriate infrastructure layer, such as the application, reverse proxy, web server or CDN.

Recommended approach

  1. Inventory existing response security headers.
  2. Identify the security controls applicable to the application's architecture.
  3. Define explicit policies rather than relying on browser defaults.
  4. Remove unnecessarily broad origins and capabilities.
  5. Configure HTTPS enforcement appropriately for the deployment.
  6. Prevent unnecessary MIME sniffing where applicable.
  7. Define an appropriate referrer policy.
  8. Restrict browser capabilities that the application does not require.
  9. Review cross-origin policies where the application requires them.
  10. Test the resulting configuration against all legitimate application functionality.
  11. Include security-header configuration in the controlled deployment baseline.

Example baseline

Response headers CONCEPTUAL 
Content-Security-Policy:
    [application-specific policy]

Strict-Transport-Security:
    [deployment-appropriate HTTPS policy]

X-Content-Type-Options:
    nosniff

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

Permissions-Policy:
    [application-specific capability policy]
Header configuration must be tested, not merely deployed

A security header can introduce functional failures when its policy conflicts with legitimate scripts, styles, frames, APIs, third-party services or cross-origin resources. Remediation is incomplete until the resulting policy has been verified.

11 / VERIFICATION

Verification

01
Repeat the original response capture Request the same representative endpoints used during the initial assessment.
02
Confirm required headers Verify that the applicable security headers are now present with the intended values.
03
Validate policy effectiveness Confirm that the configured directives actually impose the intended browser restrictions.
04
Test legitimate functionality Verify login, navigation, scripts, forms, embedded content, APIs and other required functionality.
05
Review alternate response paths Check authenticated pages, errors, redirects and other relevant response classes for consistency.
06
Verify persistence Confirm that the configuration survives the normal deployment, restart and infrastructure configuration process.
PASS

Applicable security headers are correctly configured and legitimate application functionality continues to operate.

FAIL

Applicable controls remain absent, weak, inconsistent or unnecessarily permissive.

NOT TESTED

The relevant header configuration or browser behavior could not be adequately evaluated.

12 / EVIDENCE

Evidence requirements

Tested endpoint or resource
HTTP response status
Relevant response headers
Original configuration
Security impact
Remediated configuration
Post-remediation response
Functional compatibility verification
Alternate response-path verification
Final PASS / FAIL determination
Remove sensitive deployment information

Publicly published evidence should not reveal internal hostnames, private origins, credentials, tokens, proprietary infrastructure details or other sensitive configuration information.

13 / CLASSIFICATION

Classification

WebOTG procedure WebOTG-SM-025
OWASP category A02:2025 — Security Misconfiguration
Procedure type HTTP security-header and browser-policy configuration review
Assessment result PASS / FAIL / NOT TESTED
Finding severity Determine according to the affected browser security control, application exposure and resulting security impact.
WebOTG classification notice

WebOTG-SM-025 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 Testing methodology relevant to HTTP security configuration.
OWASP Application Security Verification Standard Verification requirements relevant to secure browser and HTTP configuration.
HTTP security-header specifications Authoritative definitions of applicable HTTP security policies and directives.
Organization security baseline Defines approved security-header configuration for the deployment.

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.