How to Add an Authorization Header for Testing

Last updated 2026-08-05

You want to open an API endpoint in a browser tab, or let a frontend you are debugging call a protected endpoint, without writing auth code first. A header rule attaches the token for you. This is a genuinely useful trick and also the easiest way to leak a credential, so the scoping matters as much as the header.

The rule

Match:  domain is api.example.com
Action: set request header  Authorization: Bearer eyJhbGciOi...

Use set rather than append. Chrome only allows append on a short allowlist of request headers, and Authorization is not on it. Appending a second credential to an existing one would not be meaningful anyway.

Scope it, then scope it again

• Match by domain, never by wildcard: a rule matching * sends your token to every site you visit, including any page that happens to load a third-party script. Treat a broad Authorization rule as a token you have already published.
• Add the path if the API shares a host with a website: a contains match on /api/ keeps the header off ordinary page loads.
• Limit the resource type: most API traffic is xmlhttprequest. Restricting to it keeps the header off document, image, and font requests.
• Keep it in its own profile: one profile per environment, disabled by default. Turning auth on for a session is then one toggle, and forgetting it is much harder.
• Prefer short-lived tokens: a token stored in an extension rule is a token sitting in your browser profile. Use one that expires, and re-paste it rather than reaching for a long-lived key.

Never do this with a production credential that has write access. If the endpoint can delete something, get a read-only or sandbox token instead. Extension storage is not a secret manager.

Other auth headers you may need

When it still returns 401 or 403

1. Confirm the header arrived. In DevTools, Network, select the request and read Request Headers. If it is not there, the rule did not match or host access was not granted.
2. Check for a preflight. Any custom header on a cross-origin request triggers an OPTIONS preflight, and the browser does not attach your Authorization header to it. The server must answer the preflight with Access-Control-Allow-Headers: authorization before the real request is sent. See fixing CORS in local development.
3. Check for a competing rule. Two rules setting the same header on the same URL resolve by priority, and the loser is silent.
4. Check the token itself with curl, which removes the browser from the question entirely.
5. Check the scheme spelling. Bearer with a capital B and exactly one space is what most servers parse.

curl -i https://api.example.com/v1/me \
  -H 'Authorization: Bearer eyJhbGciOi...'

Removing auth is a test too

A remove rule on Authorization is the fastest way to see what an unauthenticated user gets: does the API return a clean 401, or a 500 with a stack trace? Does the frontend show a sign-in prompt, or an empty screen that looks broken? Toggling the header off for a minute answers both.

Common questions

Is it safe to store an API token in a browser extension rule?

It is as safe as anything else in your browser profile, which is to say: fine for development tokens, wrong for production secrets. The rule sits in local extension storage, readable by anyone with access to your profile. Use short-lived, low-privilege tokens and delete the rule when you are done.

Why does my Authorization header not appear on the preflight request?

By design. The browser sends the OPTIONS preflight without your custom headers, listing them in Access-Control-Request-Headers instead. The server has to allow them in its response before the real request is sent, so a preflight that fails will look like your header never worked.

Can I set different tokens for different environments?

Yes, and profiles are the clean way to do it: one profile per environment, each with its own rule matched to that environment’s host, and only one enabled at a time. Matching by host also means the wrong token cannot reach the wrong API.

Does this work for requests my JavaScript makes with fetch?

Yes. Header rules apply to the network request, whichever layer created it, so fetch, XHR, form posts, and top-level navigations are all covered as long as the URL matches.