Legacy Feature-Policy header also set
Why it matters
Safari does not recognize the Permissions-Policy header name — it only supports the older Feature-Policy header. Sites that configure Permissions-Policy without a matching Feature-Policy leave Safari users with no API restrictions at all: camera, microphone, geolocation, and payment APIs remain unrestricted for embedded content. CWE-693 applies when a protection mechanism is deployed in a way that bypasses it for a significant user segment. OWASP A05 flags browser-specific security header gaps as misconfiguration — partial cross-browser coverage is operationally equivalent to no coverage for affected users.
Severity rationale
Low because Safari's market share is significant (especially on mobile), and omitting `Feature-Policy` leaves that entire segment without any API permissions restrictions despite `Permissions-Policy` being configured.
Remediation
Set both Permissions-Policy (Chromium/Firefox) and Feature-Policy (Safari) with matching restrictions. The syntax differs: Feature-Policy uses 'none' instead of () and semicolons instead of commas.
headers: [
{
key: 'Permissions-Policy',
value: 'camera=(), microphone=(), geolocation=()'
},
{
key: 'Feature-Policy',
value: "camera 'none'; microphone 'none'; geolocation 'none'"
}
]
Skip this step only if you have confirmed your deployment target is Chromium-only (Chrome extension, Electron app, kiosk). For public web apps, both headers are required.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Security Headers II Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-693
- owasp:2021 · A05
Taxons
History
- 2026-04-18·v1.0.0·Initial import from security-headers-ii·automated