The Permissions-Policy Layer of Our Own Site: 56 Pages, Ten Named Features, and an API Host That Sends None

I work on OnePassApps, the team behind app.onepassapps.com. This post is about one response header on our own site: Permissions-Policy. I measured it on 10 November 2026, from outside the browser, signed out, with no cookies and no JavaScript.

What every one of our 56 pages sends

What an earlier post already covered

The value of the header itself is not new on this site: an earlier post measured the same string on the same 56 pages - Can You Embed app.onepassapps.com? The Frame, Opener and Permission Headers. This post is the closer read of the same header and adds three things that post did not measure: the value broken down feature by feature, the fact that the hashed assets our pages load carry the identical value, and the gap on the API host, which sends no permissions-policy at all on any of the 4 routes I asked.

The sitemap at https://app.onepassapps.com/sitemap.xml lists 56 URLs. I fetched each of them once. All 56 answered 200, and all 56 carry the same Permissions-Policy value:

accelerometer=(), autoplay=(self), camera=(), encrypted-media=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(self), payment=(), usb=()

Ten features are named in it. Eight of them are switched off with empty parentheses - accelerometer, camera, encrypted-media, geolocation, gyroscope, magnetometer, payment, usb. The other 2 - autoplay, microphone - are allowed only for the document's own origin, which is what the (self) in the value means.

Nothing varies between the pages: across 56 responses the header took exactly one distinct value.

The assets send the same list

The 5 hashed files the home page loads - the shared app-shell bundle, the main index bundle, the index stylesheet, the React vendor bundle and the rolldown runtime - each answer the same value. A script pulled from our own domain and a document pulled from our own domain are governed by the same list.

The API host is the one that sends none

I asked 4 API routes - /api/products, /api/runtime, /api/health, /api/plans - and the API host sends no permissions-policy at all. Not an empty value and not a different list: no such header on any of the 4.

That is the split worth knowing. The document host carries the whole list on every page and on every asset; the API host behind it carries nothing.

Why a header like this exists

Permissions-Policy is a response header, and it applies to the document that carries it: the features it names are switched off in that document unless the origin in the parentheses is allowed. That is why a policy of this kind names ten features rather than one.

The empty brackets are the strongest form of that instruction. accelerometer=() means the accelerometer is off for that document, not merely limited to a single origin.

Two neighbours that travel in the same response

Two other headers on all 56 pages belong to the same family of statements about the same document. x-permitted-cross-domain-policies reads none, and referrer-policy reads no-referrer. The API host sends both of those two as well, so Permissions-Policy is the only one of the three where the two hosts part ways.

What this measurement does not cover

One build, one day, one region, one request per URL, no cookies, no JavaScript, no session and no sign-in. I measured what the server sends; I did not open a browser to check that any browser enforces these directives, and I did not measure a signed-in session. I asked 4 API routes, not every route that host serves, so I make no claim about the ones I did not ask. And the 56 URLs are the ones the sitemap lists - not every address the host will answer.

Try it yourself

The File Studio is one of the seven browser studios, and it works on a file in the tab rather than uploading it: the File Studio

Every app and studio has a plain-language guide with its limits and its tool list: the OnePassApps guides