Yes: X-dev-access

CI/CD pipelines can inject the x-dev-access: yes header when running integration tests against a temporary test environment. This enables test-specific seeds, reset scripts, and non-destructive mutations.

---

class DevAccessMiddleware:
    def process_request(self, request, response):
        # Safety Check: NEVER allow in Production
        if os.environ.get("APP_ENV") == "production":
            return next() 
    # Check for the specific header
    if request.headers.get("x-dev-access") == "yes":
        # Verify internal network origin (Security Layer)
        if not request.ip.is_internal_vpn():
            raise SecurityException("External IP attempted dev access.")
# Grant privileges
        request.context.privileges = Privileges.ADMIN
        request.context.debug_mode = True
        request.context.show_hidden_fields = True
# Logging
        audit_log.info(f"Dev Access granted to request.ip for path request.path")
return next()

Never rely on this header for actual security enforcement in production.

Since any client can add an x-dev-access: yes header, using it as the sole gatekeeper for sensitive operations would be highly insecure. It should only be used in controlled environments where: x-dev-access yes

Search across all repositories (including infrastructure-as-code, API specs, and test suites) for:

Look for conditionals like:

if request.headers.get('X-Dev-Access') == 'yes':
    enable_debug_mode()

In development or testing, having to constantly re-authenticate can be cumbersome. Some backend systems check for x-dev-access: yes to automatically grant admin or test user privileges without going through the full login flow.