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

WebOTG-SM-017 — Missing or Misconfigured Security Headers

A structured procedure for identifying missing, weak or incorrectly configured HTTP response security headers and determining whether the configuration creates a meaningful security weakness.

WebOTG ID SM-017 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 security headers appropriate to the application's architecture and that those headers are correctly configured without weakening the intended browser security controls.

Security headers allow an application to communicate security-related policies to user agents. Depending on the application, these policies can reduce risks such as clickjacking, MIME-type confusion, unintended cross-origin behavior and unsafe browser feature use.

Header testing must be performed in the context of the application. A missing header is not automatically a vulnerability, and a stronger-looking header value is not necessarily safer if it breaks required application behavior.

Avoid checklist-only header testing

The objective is not to maximize the number of security headers. Determine which controls are applicable, whether they are correctly configured and whether their effective browser behavior matches the application's security requirements.

02 / SCOPE

Scope

Review security-related response headers on:

Public HTML pages
Authenticated application pages
Authentication and session endpoints
API responses where applicable
Static resources where security policy requires review
Error responses
Redirect responses
Reverse proxy and gateway responses
03 / PREREQUISITES

Prerequisites

Authorization Confirm authorization to assess the application's HTTP responses.
Browser-based application Determine whether the application relies on browser features affected by security response headers.
Content Security Policy Identify whether the application uses a Content Security Policy and whether it is deployed as a response header or another supported mechanism.
Architecture Identify web servers, reverse proxies, CDNs and application layers capable of adding, modifying or removing headers.
04 / METHODOLOGY

Methodology

Review actual HTTP responses, determine the effective browser-facing security policy and compare the result with the application's documented requirements.

Review Purpose
Header presence Determine whether applicable security headers are returned.
Header value Determine whether each header expresses the intended security policy.
Header consistency Compare responses across representative application paths and status codes.
Browser effect Where necessary, validate the effective browser behavior rather than relying only on the raw header string.
Infrastructure behavior Determine whether a proxy, CDN or web server changes the security policy.
05 / PROCEDURE

Test procedure

01
Select representative responses Include normal pages, authenticated pages, redirects and error responses where applicable.
02
Capture response headers Record the complete response-header set while excluding sensitive values from published evidence.
03
Identify applicable security policies Determine which headers are relevant to the application's technologies, content and browser interaction model.
04
Review policy values Determine whether each applicable header is configured correctly and consistently.
05
Check security-sensitive paths Verify that authentication, account, administrative and other sensitive responses do not lose required security controls.
06
Assess practical impact Determine what security property is weakened by the configuration and whether the weakness is material to the application's threat model.
07
Record baseline behavior Preserve the tested endpoint, response status, relevant headers and final assessment result.
06 / HEADER REVIEW

Security header review

The following headers are common areas for review. Applicability depends on the application's architecture and browser-facing functionality.

Content-Security-Policy
Defines restrictions for resources and browser execution contexts. Review policy strength, required sources and unsafe exceptions.
Strict-Transport-Security
Instructs supporting user agents to use HTTPS for applicable requests. Review deployment prerequisites, scope and policy values.
X-Content-Type-Options
Helps prevent MIME-type sniffing when configured appropriately.
Referrer-Policy
Controls referrer information sent with requests. Review the policy against privacy and application requirements.
Permissions-Policy
Controls access to selected browser capabilities. Review whether unnecessary capabilities are exposed.
Cross-Origin-Opener-Policy
Controls document relationship and browsing-context isolation. Applicability depends on application behavior.
Cross-Origin-Resource-Policy
Controls cross-origin resource loading behavior. Review only where the application's resource model requires it.
Cross-Origin-Embedder-Policy
Controls embedding requirements for cross-origin resources and may be required by applications using cross-origin isolation.
X-Frame-Options
Provides legacy-compatible clickjacking protection for supporting user agents. Review alongside the application's framing policy.

Example response

HTTP response 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=()
Header presence is not sufficient

A header can be present while its value is ineffective, overly permissive or incompatible with the intended security policy. Always assess the actual directive or value.

07 / ASSESSMENT

Assessment

Condition Assessment consideration
Header present and correctly configured Generally satisfies the relevant configuration requirement.
Header absent but not applicable Do not raise a finding solely because a generic scanner expects the header.
Header absent and security property is required Determine the resulting security impact before classifying the issue.
Header present with weak value Assess the effective policy and identify the security control that is weakened.
Inconsistent headers Determine whether sensitive endpoints receive weaker protection than intended.
Conflicting policies Determine the effective browser behavior and document the configuration conflict.
08 / EXPECTED RESULT

Expected result

Pass condition

Applicable security headers are intentionally configured, their values implement the required browser security policies, and the configuration remains consistent across relevant application responses.

Security-sensitive responses should not unintentionally lose protections because a reverse proxy, CDN, error handler or alternate application path uses a different response configuration.

09 / FAILURE CRITERIA

Failure criteria

An applicable security policy is absent and the absence creates a material security weakness.
A security header is present but configured in a way that materially weakens the intended control.
Sensitive application responses receive weaker security policies without a justified reason.
A reverse proxy, CDN or web server removes or modifies required security headers.
Content Security Policy is deployed but contains unnecessary broad exceptions that materially reduce its intended protection.
HTTP responses expose security-sensitive functionality without the browser security controls required by the application's design.
Example finding HEADER MISCONFIGURATION

The application serves sensitive browser-facing content without an applicable security policy required by its deployment model. The missing control weakens the intended browser security boundary and should be implemented consistently across relevant responses.

10 / REMEDIATION

Remediation

Define a documented browser security-header baseline appropriate to the application's architecture and enforce it consistently at the correct infrastructure or application layer.

Recommended approach

  1. Identify the browser security properties relevant to the application.
  2. Define approved header names and policy values.
  3. Implement the policies at a controlled server, application or gateway layer.
  4. Avoid unnecessarily permissive policy directives.
  5. Review Content Security Policy sources and exceptions carefully.
  6. Configure HTTPS transport policy appropriately for the production deployment.
  7. Apply the intended configuration consistently to normal, authenticated and security-sensitive responses.
  8. Verify that CDNs, reverse proxies and error handlers do not remove or alter required headers.
  9. Test application functionality after policy changes.
  10. Record the approved header baseline for future configuration audits.

Example baseline

Illustrative policy EXAMPLE 
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=();
Do not copy a generic CSP blindly

Content Security Policy is application-specific. Copying a restrictive policy without understanding the application's scripts, styles, frames and third-party dependencies can break functionality. Build and test the policy against the actual application.

11 / VERIFICATION

Verification

01
Request representative pages Capture responses from public and authenticated application areas.
02
Compare the security-header baseline Verify that required headers and values are present where applicable.
03
Test redirects and errors Confirm that security-sensitive policies are not unintentionally lost on alternate responses.
04
Validate effective browser behavior Where applicable, use browser developer tools or controlled functional testing to confirm that the intended policy is actually enforced.
05
Test application functionality Verify that legitimate scripts, resources, authentication flows and integrations continue to function.
06
Verify infrastructure consistency Confirm that the final response reaching the client contains the intended policy after processing by all intermediary layers.
PASS

Applicable browser security policies are correctly configured and consistently delivered.

FAIL

A material security-header weakness remains after remediation or the effective policy does not satisfy the documented requirement.

NOT TESTED

The effective security-header configuration could not be adequately determined.

12 / EVIDENCE

Evidence requirements

Endpoint tested
HTTP response status
Relevant response headers
Expected policy baseline
Browser behavior where relevant
Before-remediation evidence
Remediation configuration
Post-remediation response
Application functionality verification
Final PASS / FAIL determination
Sanitize captured responses

Remove cookies, bearer tokens, session identifiers, internal hostnames and other sensitive values before publishing HTTP response evidence.

13 / CLASSIFICATION

Classification

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

WebOTG-SM-017 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 and configuration review methodology.
OWASP Application Security Verification Standard Application security verification requirements relevant to browser and transport security controls.
HTTP Semantics HTTP response and request semantics relevant to application behavior.
Browser security specifications Defines behavior for applicable browser security mechanisms and policies.

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.