Preserve framework security controls across the request lifecycle

Frameworks provide useful security mechanisms, but they protect only the paths that use them correctly. An authenticated page may use escaped templates, CSRF middleware and an ORM, while a newly added JSON endpoint bypasses one of those layers. A setting named secure is not an end-to-end property. Trace a request from proxy and router through parsing, session handling, request-intent protection, authorization, database access, serialization and response headers. Identify the exact framework, security modules and deployment mode before copying configuration from another project: the concepts transfer, but configuration names and extension points do not.

The example is a cookie-authenticated profile rename. The intended sequence is authenticate Alice, validate a session-bound CSRF token, authorize Alice's profile, validate the allowed name field, bind the database update and render the new name as text. Each step has a separate purpose. The ORM prevents SQL syntax injection in ordinary parameterized queries; it does not prove Alice owns the selected row. Template escaping protects an output context; it does not validate a URL or authorize a state change.

Middleware-only authorization fails when a request can skip the middleware. In March 2025, CVE-2025-29927 (CVSS 9.1) showed that a request carrying the internal x-middleware-subrequest header could bypass Next.js middleware altogether, so applications whose only authorization check ran there exposed protected pages until they upgraded to 12.3.5, 13.5.9, 14.2.25 or 15.2.3. Keep a check where the data is read, so one skipped layer does not expose it.

A common regression adds an API route with a CSRF exemption because the frontend's first request fails. If the route still accepts a session cookie, the original forgery model remains; the correct repair is to send the framework token through its documented integration, as /domains/appsec/browser-security/csrf-origin-defense/ describes. Make deliberate exceptions only for webhooks or machine clients that use their own authentication contract, such as a provider signature, and never disable a browser control for a whole prefix to accommodate one integration. Spring Security and Django have specific request and token lifecycle behavior, so use the documentation for the deployed version instead of transferring a code fragment between frameworks.

Authentication must precede business authorization, and rejected requests must stop before mutation. Parsing limits should apply before oversized bodies consume excessive work. Method overrides, subrouters and exception handlers can change which middleware executes. Behind a trusted proxy, configure external scheme and host handling so secure-cookie and origin decisions use validated infrastructure metadata. Arbitrary forwarded headers must not redefine the application's origin or turn a plain request into a trusted secure request. Check host validation, secure cookie settings, debug mode and production error responses through the actual reverse proxy.

The settings below are the production security block for a Django 6 project behind a TLS-terminating proxy. They turn off debug output, restrict hosts, redirect to HTTPS, send HSTS for a year, mark the session and CSRF cookies Secure, and use Django 6.0's built-in Content Security Policy with a per-response nonce and 'strict-dynamic'. SECURE_PROXY_SSL_HEADER is safe only when the proxy sets X-Forwarded-Proto itself and removes any value a client sent. In a test project, manage.py check --deploy --fail-level WARNING reported no issues on Django 6.0.9 and 6.1.1, a plain-HTTP request was redirected, an unknown Host received 400, and the page's script nonce matched the one in the Content-Security-Policy header.

# settings_production.py (Django 6.0+): security settings that `manage.py check --deploy` expects.
import os

from django.utils.csp import CSP

DEBUG = False
SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]  # 50+ random characters, never committed
ALLOWED_HOSTS = ["app.example.test"]

# HTTPS behind a proxy that sets X-Forwarded-Proto and strips it from client requests.
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")
SECURE_SSL_REDIRECT = True
SECURE_HSTS_SECONDS = 31_536_000
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_HSTS_PRELOAD = True  # only after submitting the domain to the preload list
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
CSRF_TRUSTED_ORIGINS = ["https://app.example.test"]

# Content Security Policy, built in since Django 6.0; templates use nonce="{{ csp_nonce }}".
SECURE_CSP = {
    "default-src": [CSP.SELF],
    "script-src": [CSP.NONCE, CSP.STRICT_DYNAMIC],
    "object-src": [CSP.NONE],
    "base-uri": [CSP.NONE],
    "form-action": [CSP.SELF],
    "frame-ancestors": [CSP.NONE],
}

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.middleware.csp.ContentSecurityPolicyMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.contrib.messages.middleware.MessageMiddleware",
    "django.middleware.clickjacking.XFrameOptionsMiddleware",
]

Each framework has a short list of settings that decide whether its protections apply in production. Check them in the deployed configuration, because an environment variable can re-enable debug output or remove a middleware class that the source tree looks correct about. Each stack page under /fix/, such as /fix/stack/python-django/ or /fix/stack/java-spring/, lists tested fixes and the baseline versions they assume.

An ORM's raw-SQL API may safely accept separate parameters, but concatenating a sort expression or filter into its source text still grants SQL syntax. A template's raw-HTML helper intentionally disables normal escaping and needs a reviewed sanitizer policy if its input is untrusted. Automatic form or entity binding may make a newly added role field writable unless the operation explicitly selects fields; the mass assignment fix cards at /fix/mass-assignment/ show explicit field selection per framework. These interfaces are useful precisely because they permit behavior outside the default safety boundary.

Review defaults in the actual configuration rather than relying on a framework's marketing or a prior project. Debug mode, allowed hosts, cookie attributes, session storage and dependency patch level all influence deployed behavior. A reverse proxy may generate an error document without the application's headers, or a cache may serve an authenticated response to another user. Keep explicit projections and authorization at the resource path so framework conveniences cannot silently widen the operation when the data model changes. Review background tasks separately: a queued job does not pass through the request middleware that authorized the interactive request, so it must check membership and tenant again when it runs.

• CSRF exemptions on routes that still accept session cookies.
• Raw SQL built by concatenation, even through an ORM's raw-query API.
• Raw HTML helpers such as |safe, th:utext, Html.Raw and html_safe on untrusted values.
• Automatic binding of requests to entities, fields = '__all__' and permit!.
• Custom exception handlers that log a denial and continue.
• Debug flags, admin consoles and actuator or metrics endpoints left reachable in production.

Start with a normal rename that persists exactly one allowed field and renders punctuation correctly. Remove the CSRF token while preserving the cookie, change the profile id while preserving the valid token, supply an extra role field and submit markup as the name. Each variation isolates a different boundary. Check stored values and rendered structure, not just whether the response is successful.

For operational diagnosis, record which layer rejected the request through an internal category and request id. Repeated token failures after a release may reflect middleware ordering or frontend integration; ownership denials may reflect an incorrect route id. Resist resolving both by disabling guards. Maintain a small request-lifecycle suite for representative routes and repeat it when upgrading the framework, changing routers, adding a proxy or replacing serializers. Framework defaults reduce repetitive work when the application's boundaries stay aligned with them.

A framework upgrade can change defaults, middleware behavior, serializer handling or the supported security API. Preserve your application's behavioral contract across that change instead of merely adapting code until it starts. The rename suite provides concrete probes: missing token still denies, foreign id still denies, unknown role still rejects atomically and markup-shaped names remain text. If a test changes, explain whether the framework behavior changed or the application's policy intentionally changed.

Dependencies around the framework matter too. A JSON body parser may accept shapes the handler did not expect; a session backend outage may affect authentication; a proxy may alter origin metadata; a template plugin may reinterpret strings. Trace each integration at its own interface and include failure behavior. A fallback authentication path should never turn a session-store outage into an anonymous user with default administrative permission. Pin the supported framework version range, track its security releases and retire unsupported branches with an explicit migration plan.

Deployment validation should inspect effective configuration. An environment variable can enable debug output or disable a middleware class despite reviewed source settings. Test the packaged application through the actual proxy and routing arrangement using synthetic data. A local unit test of a view function is valuable, but does not demonstrate that deployed middleware runs in the same order or that the error response avoids a debug page. Keep those verification scopes distinct in the release record so defaults remain useful, observable guarantees rather than assumptions.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. Spring Security CSRF integration
2. Django: security in Django. Django 6.1.
3. Django: deployment checklist. Django 6.1.
4. Django 6.0 release notes: Content Security Policy support
5. GitHub advisory GHSA-f82v-jwr5-mffw: Next.js middleware authorization bypass
6. Express: production security best practices
7. Ruby on Rails security guide

Reference information

Tags

Secure defaults and frameworksJavaPython

SDLC phase

Development

Role

DevelopersAppSec engineers

ASVS 5.0.0 requirements

v5.0.0-13.4.2 · v5.0.0-3.3.1 · v5.0.0-3.4.1 · v5.0.0-3.4.3 · v5.0.0-15.3.4

Download this guide as Markdown

Continue exploring