Feature Policy / Permission Policy

Permission Policy, earlier called Feature Policy, is a browser security mechanism used to control which powerful browser features can be used by a webpage or by embedded third-party content like iframes.

It helps us restrict access to sensitive features such as:

• geolocation
• camera
• microphone
• audio/video
• fullscreen
• autoplay
• accelerometer
• battery and other browser APIs

What It Is

Permission Policy allows developers to explicitly declare what browser features are allowed or blocked on a website.

Simple meaning:

Browser feature exists
        ↓
Website or iframe tries to use it
        ↓
Permission Policy checks whether it is allowed
        ↓
Feature is allowed or blocked

This is useful because modern web apps often use:

• third-party scripts
• iframes
• embedded widgets
• external content

Without restrictions, those scripts or iframes may try to access browser features like geolocation, microphone, or camera.

Why It Matters

We cannot blindly trust every third-party script or iframe loaded inside our application.

Example risk:

Third-party iframe/script
        ↓
Tries to access geolocation or microphone
        ↓
Browser allows it if policy is not restricted
        ↓
User privacy and app security may be affected

Permission Policy helps us enforce rules even when the codebase grows or third-party content is added later.

Main benefits:

Benefit	Meaning
Better privacy	Sensitive APIs can be blocked
Safer third-party content	Iframes can be restricted
Controlled browser features	Only required features are enabled
Better security defaults	Features are denied unless allowed
Performance control	Some features/scripts can be restricted when not needed

Core Flow

Permission Policy works like this:

Server sends Permissions-Policy header
        ↓
Browser receives the policy
        ↓
Page or iframe tries to use a browser feature
        ↓
Browser checks allowlist
        ↓
Feature is allowed or blocked

For iframes:

Parent page adds iframe allow attribute
        ↓
Iframe tries to access feature
        ↓
Browser checks iframe-specific permission
        ↓
Feature is allowed or blocked only for that iframe

Main Security Goals

The PDF explains these main goals of Permission Policy:

Goal	Example
Restrict sensitive devices	Block camera, microphone, speakers
Control geolocation access	Block or allow location APIs
Control autoplay behavior	Change autoplay behavior for videos
Control iframe features	Allow iframe to use fullscreen only when needed
Improve safety with third-party content	Restrict embedded scripts/iframes
Improve performance	Stop unnecessary feature usage

Permission Policy vs Content Security Policy

Permission Policy is similar to Content Security Policy, but both control different things.

Policy	Controls
Content Security Policy	Security behavior like script, style, image, and resource loading
Permission Policy	Browser features like camera, microphone, geolocation, fullscreen

Simple difference:

CSP controls what resources can load.
Permission Policy controls what browser features can be used.

Ways to Specify Permission Policy

The PDF mentions two ways to define policies.

Method	Scope
Permissions-Policy HTTP header	Controls feature usage for the page response and embedded content
<iframe allow=""> attribute	Controls feature usage only for a specific iframe

Header Syntax

Basic syntax:

Permissions-Policy: <directive>=<allowlist>

Example:

Permissions-Policy: geolocation=()

Meaning:

geolocation=()
        ↓
Disable geolocation access

Allowlists

An allowlist defines where a feature is allowed.

Allowlist Value	Meaning
*	Feature is allowed for the document and all nested iframes
()	Feature is disabled in top-level and nested contexts
self	Feature is allowed only for the same origin
src	Feature is allowed in an iframe if its loaded document matches iframe src origin
"https://example.com"	Feature is allowed only for a specific origin

Important notes:

• * and () are used alone.
• self and src can be combined with specific origins.
• In HTTP headers, origins are written inside quotes.
• In iframe allow attributes, origins are not quoted.

Example:

Permissions-Policy: geolocation=(self "https://trusted-site.example")

Meaning:

Allow geolocation for same origin
and also for https://trusted-site.example

Common Directives

Permission Policy can control many browser features.

Examples from the PDF:

• accelerometer
• battery
• camera
• microphone
• geolocation

Simple example:

Permissions-Policy: camera=(), microphone=(), geolocation=()

Meaning:

Block camera
Block microphone
Block geolocation

Example Without Permission Policy

Imagine a server returns a page that contains a script to access geolocation.

const express = require("express");
const app = express();

app.get("/page", (req, res) => {
  res.send(`
    <!DOCTYPE html>
    <html lang="en">
    <head>
      <meta charset="UTF-8" />
      <meta name="viewport" content="width=device-width, initial-scale=1.0" />
      <title>Fetch Geolocation Permission Example</title>
    </head>
    <body>
      <h1>Fetch Geolocation Permission Example</h1>
      <button onclick="getGeolocation()">Fetch Data</button>
      <div id="result"></div>

      <script>
        function getGeolocation() {
          if (navigator.geolocation) {
            navigator.geolocation.getCurrentPosition(
              function (position) {
                const latitude = position.coords.latitude;
                const longitude = position.coords.longitude;

                console.log("Latitude:", latitude);
                console.log("Longitude:", longitude);
              },
              function (error) {
                console.error("Geolocation error:", error);
              }
            );
          } else {
            console.error("Geolocation is not supported by this browser.");
          }
        }
      </script>
    </body>
    </html>
  `);
});

const port = process.env.PORT || 5010;

app.listen(port, () => {
  console.log(`Server is running on port ${port}`);
});

If the script is coming from a third party and we do not restrict geolocation, clicking the button can log latitude and longitude.

Flow:

User clicks button
        ↓
Script calls navigator.geolocation
        ↓
Browser allows geolocation
        ↓
Latitude and longitude are logged

Blocking Geolocation

If we do not want geolocation access, we can set the Permissions-Policy header.

app.use((req, res, next) => {
  res.setHeader("Permissions-Policy", "geolocation=()");
  next();
});

Now the flow becomes:

User clicks button
        ↓
Script calls navigator.geolocation
        ↓
Browser checks Permissions-Policy
        ↓
geolocation=() blocks access
        ↓
Browser denies geolocation request

This is useful when third-party scripts or iframes should not access user location.

iframe allow Attribute

Permission Policy can also be applied to a specific iframe using the allow attribute.

Example:

<iframe src="https://trusted-site.example" allow="geolocation"></iframe>

This controls feature usage only for that iframe.

Another example:

<iframe src="https://video.example" allow="fullscreen"></iframe>

Meaning:

Only this iframe is allowed to use fullscreen.

Use iframe-level policy when you want more control over individual embedded content.

Example Allow and Block Flow

A page can allow geolocation only for selected origins.

Example:

Permissions-Policy: geolocation=(self "https://trusted-site.example")

Possible behavior:

Same-origin page code             -> allowed
Same-origin iframe                -> allowed
Trusted site iframe               -> allowed
Untrusted third-party iframe      -> blocked
Ad iframe                         -> blocked

Mental model:

Policy decides which origin can use which feature.

Where to Check Permission Policy in Browser

The PDF shows that allowed and blocked Permission Policy features can be checked in browser DevTools.

Path:

DevTools
        ↓
Application tab
        ↓
Sidebar
        ↓
Frames section
        ↓
Permission Policy

This helps developers verify which features are allowed or disabled for the current page and frames.

Example Demo Reference

The PDF also mentions a Permission Policy demo page:

https://permissions-policy-demo.glitch.me/

You can use this type of demo to understand how different policies affect browser features.

Basic Checklist

Use this checklist while applying Permission Policy:

• Identify which browser features your app really needs.
• Block sensitive features that are not required.
• Restrict camera, microphone, and geolocation by default.
• Be careful with third-party scripts and iframes.
• Use the Permissions-Policy header for page-level control.
• Use iframe allow attribute for iframe-level control.
• Prefer allowing only trusted origins.
• Use () to disable a feature.
• Use self when only same-origin access is needed.
• Check policies in DevTools under Application → Frames → Permission Policy.

Interview Style Answer

Permission Policy is a browser security mechanism that allows developers to control which browser features can be used by a webpage or embedded iframe. It is useful when an application uses third-party scripts or iframes and we want to prevent them from accessing sensitive APIs like geolocation, camera, microphone, or fullscreen without permission.

It can be configured using the Permissions-Policy HTTP header for the whole page or using the allow attribute for specific iframes. For example, Permissions-Policy: geolocation=() disables geolocation access. It is similar to Content Security Policy, but CSP controls resource loading and security behavior, while Permission Policy controls browser feature access.

One-Line Summary

Permission Policy controls which browser features a page or iframe is allowed to use.

Final Mental Model

Page/Iframe asks for browser feature
        ↓
Browser checks Permission Policy
        ↓
Feature is allowed or blocked

Remember it like this:

CSP controls resources.
Permission Policy controls browser features.

Or:

Do not let every script or iframe access camera, mic, location, or fullscreen by default.