uWSGI Router Header Injection for Django/Flask Accessibility

Direct answer

uWSGI can inject static response headers globally with --add-header and conditionally with internal routing actions such as route-uri paired with addheader. It cannot reliably prevent duplicate headers when the Django or Flask application also emits the same header, because uWSGI evaluates routes before the WSGI app produces its response. ARIA attributes cannot be exposed as HTTP headers at all; they are DOM properties. In an Emperor deployment, header policy must be explicitly propagated to vassals or defined per vassal.

What uWSGI can and cannot do

Confirmed behavior: --add-header appends a fixed header to every response. Path- or host-based injection uses routing rules (route-uri, route-host, route-if) with an addheader action. Values should be static and quoted, especially CSP directives containing spaces and semicolons.

Duplicate prevention is the hard constraint. uWSGI routing runs before the WSGI application, so uWSGI does not know whether Django or Flask already set Content-Security-Policy or X-Content-Type-Options. If both sides set them, clients may receive repeated headers. uWSGI does not inspect or rewrite the application's response headers in this flow.

ARIA compliance attributes (role, aria-label, aria-live, etc.) are HTML attributes consumed by browsers and assistive technology. HTTP headers do not enter the accessibility tree. Adding X-ARIA-* headers would create a false sense of compliance without changing rendered markup.

Recommended configuration pattern

1. Choose a single owner for each header. If uWSGI owns CSP and nosniff, remove them from Django/Flask middleware.
2. For global static values, use --add-header "Content-Security-Policy: default-src 'self'" and --add-header "X-Content-Type-Options: nosniff".
3. For selective injection, use route-uri with an addheader action, keeping values static and allowlisted.
4. Verify with curl -sI that matching and non-matching paths return exactly one CSP and one nosniff header.
5. If you need per-request nonces, hashes, or dedupe against app-level headers, place a reverse proxy in front of uWSGI instead.

Emperor multi-tenant considerations

Do not assume emperor-level options automatically apply to vassals. Use the vassal propagation mechanism supported by your uWSGI build, or set the header policy in each vassal configuration. A single broad CSP across tenants can weaken a strict application or break another that requires different script, style, or asset origins.

Security mitigations

• Allowlist static header values; never build CSP from request host, path, or tenant data.
• Reject values containing CR/LF to prevent response splitting.
• Keep tenant-specific CSP in the application or edge proxy when policies differ.
• Restrict who can edit Emperor and vassal configs, and run vassals as separate least-privilege users where possible.

Verification checklist

• Run uwsgi --help on the target binary and grep for add-header, route-uri, and addheader to confirm exact tokens.
• Temporarily add the same headers in the WSGI app to see whether your build appends duplicates or replaces them.
• Launch two Emperor vassals with different apps and confirm the forced header policy applies only where intended.

Because exact option spelling and Emperor inheritance behavior are version- and build-sensitive, confirm them on your deployed binary. If your uWSGI build does not expose addheader in routing help, or if your applications already emit CSP/nosniff, share the relevant uwsgi --help output and the current header ownership model; that determines whether uWSGI alone is safe or a proxy is required.