Your browser has access to your camera, microphone, GPS location, USB ports, and much more. Every web page you open can potentially request access to these resources, even if you never explicitly granted permission to that specific site. Permissions Policy gives you control over this: you can explicitly forbid certain capabilities from being used on your site, regardless of what plugins, ads, or embedded content try to do.
What Is Permissions Policy?
Permissions Policy (formerly known as Feature Policy) is an HTTP header that defines which browser features may be used on your site and in any iframes it contains. You send it as a single line of text, and the browser enforces it as law for the entire visit.
For example, if your blog has nothing to do with cameras, you can tell the browser: “No script, no plugin, no iframe on this site may ever access the camera.” The browser guarantees this, even if a malicious script manages to get injected, it cannot activate the camera.
Scenario: How This Can Be Abused Without Protection
Imagine a visitor comes to your blog. Your site has a third-party widget embedded, say, a live chat or review plugin. That plugin has been compromised in a supply chain attack: an attacker injected malicious code into one of the plugin’s versions, and that code is now attempting to:
- Activate the microphone and record the conversation in the room
- Read the visitor’s GPS location
- Access the clipboard and steal a password the user just copied
Without Permissions Policy, the browser displays a permission popup. The user can say “no”, but many click “allow” out of habit, or because they don’t understand what’s being asked.
With a Permissions Policy that says microphone=(), geolocation=(), clipboard-read=(), the browser doesn’t show any popup at all. Access is denied at the server level, before the script even tries to request it.
What Each Permission Controls and How It Can Be Abused
camera=()
Blocks access to device cameras. Without this protection, a malicious script can activate the camera and photograph or record the user. For a blog, sales, or informational site, you don’t need camera access. The only legitimate use would be video calls or direct photo uploads from the camera.
microphone=()
Blocks access to the microphone. Attackers have used compromised ad networks to attempt background audio recording. The attacker doesn’t even need to be on your site, it’s enough to inject a script through a vulnerable plugin or ad network.
geolocation=()
Blocks access to GPS location. Browsers already require explicit user permission for location, but Permissions Policy adds another layer, even if the user clicks “allow” by mistake, the server has already said location is not permitted on this site.
payment=()
Blocks the Payment Request API, the browser’s standard payment interface that can access saved cards. If your site uses Freemius, PayPal, or Stripe directly in an iframe, you need to keep this permission active for those domains. If you don’t sell anything, block it entirely.
usb=()
Blocks access to USB devices. The WebUSB API allows sites to communicate with USB devices, which is legitimate for industrial applications, but completely unnecessary for a blog or sales site. A compromised script could theoretically attempt to access USB keys or dongle devices.
clipboard-read=() and clipboard-write=()
Blocks reading and writing the clipboard (Ctrl+C / Ctrl+V content). Clipboard-read is particularly dangerous, users frequently copy passwords, PINs, card numbers. A malicious script can silently read the clipboard in the background with no visible sign.
accelerometer=(), gyroscope=(), magnetometer=()
Blocks access to motion and orientation sensors. This sounds harmless, but researchers have shown that motion data from a phone can be used to reconstruct what the user is typing (keystroke inference attack), or to track physical location even without GPS.
autoplay=()
Blocks automatic playback of video and audio without user interaction. This isn’t a direct security problem, but it’s a UX issue and can be abused for intrusive audio ads or distractions. If you don’t have video that needs to autoplay, block it.
midi=()
Blocks access to MIDI devices (musical instruments, controllers). The Web MIDI API is rare but a real attack vector, compromised sites have used MIDI access for user fingerprinting and cross-site tracking.
xr-spatial-tracking=()
Blocks access to AR/VR sensors. The WebXR API provides detailed data about the user’s environment, the room space, body position, eye movement. For anything other than AR/VR applications, this should not be accessible.
vibrate=()
Blocks vibration control on mobile devices. Mostly harmless, but can be used to annoy users or as a hidden signal to an application.
sync-xhr=()
Blocks synchronous XMLHttpRequest calls. Synchronous XHR blocks the entire browser while waiting for a server response, making it both bad for performance and a potential vector for attacks that attempt to “freeze” the user’s browser.
web-share=()
Blocks the Web Share API which allows sites to invoke the device’s native share dialog. This can be abused to share malicious links without the user’s knowledge.
Recommended Configuration for a WordPress Blog or Site
For a typical WordPress site that doesn’t sell anything directly and has no video calls:
camera=(), microphone=(), geolocation=(), usb=(), magnetometer=(), gyroscope=(), accelerometer=(), autoplay=(), encrypted-media=(), fullscreen=(), picture-in-picture=(), sync-xhr=(), clipboard-read=(), clipboard-write=(), web-share=(), midi=(), vibrate=(), xr-spatial-tracking=()If you sell and use Freemius/PayPal checkout, add:
payment=(self "https://checkout.freemius.com" "https://*.paypal.com")If you have video that needs to go fullscreen (YouTube embed, Vimeo):
fullscreen=(self)How to Enable It in Trusti Security
Permissions Policy is available in Trusti Security Premium, in the Security Headers module.
- Go to Trusti Security → Security Headers
- Enable the Permissions Policy toggle
- Choose one of the presets or enter your own configuration
- Click Save Changes
Trusti Security offers a “Strict” preset that blocks everything a typical WordPress site doesn’t need, as well as a “Custom” option where you can fine-tune each permission individually.
How to Verify Permissions Policy Is Working
In Chrome DevTools (F12 → Network tab), click on the main page document and find permissions-policy in the list of response headers. If you see it, it’s working.
You can also open the console and try running:
navigator.mediaDevices.getUserMedia({ video: true })If the camera is blocked, you’ll get a NotAllowedError immediately, without any popups.
Need Help Setting It Up?
If you’re not sure which permissions to block for your specific site, or if you have a functional requirement that conflicts with a restrictive policy, our team can help you find the right balance between security and functionality.