Create a request-header rule
Use an authorized HTTPS test service and a harmless header such as
X-Debug-Mode: enabled
. Replace illustrative screenshot hosts with a real test host.
- Install HeaderKit. Open it on an HTTPS test site. Review the privacy notice.
-
Choose
Add rule for this site
. Check the
Exact HTTPS host
, such as
api.example.com. -
Enter
X-Debug-Modeas the header name andenabledas the value. -
Narrow matching through
Optional request scoping
. Enter a prefix such as
/api/v1and select API calls (fetch/XHR) as needed. - Choose Add rule . Approve exact-host access when prompted. Keep the profile active, master switch On, and rule On.
Understand which requests match
Match the request destination, not necessarily the current page. Requests from
app.example.com
to
api.example.com
need a rule for
api.example.com
.
- An exact host does not include its sibling hosts or subdomains.
- With no optional scope, the rule covers all paths and supported request types on that HTTPS host.
-
/api/v1matches that path and its nested paths, such as/api/v1/users. It does not match/api/v10. - The fetch/XHR option excludes page loads and static assets. It does not capture requests made by curl, a terminal, or another application.
Verify it in Chrome DevTools
- Open DevTools and select Network .
- Trigger a fresh request matching the host, path, and request type.
- Open Headers → Request Headers . Check the test header. Confirm through server logs if cached or provisional headers are unclear.
- Pause the rule. Repeat the request. Confirm the added value stops applying.
If the header is missing
Check HTTPS, destination host, profile, both switches, timer, and request scope. Open Site access . Use Grant for saved rules lacking access. Check for competing extensions or applications setting the same header.
Modify request headers only. No response-header edits or CORS bypass. Configure server permission for cross-origin custom headers. Avoid production credentials. Destination logs may retain enabled values.