Web Security
A Python application is rarely broken through Python itself. What gets broken is the boundary between your code and the browser — where a user string turns into HTML, where a cookie decides whose request this is, and where a token stands in for a database lookup. Every vulnerability in this topic has the same shape: data that arrived from outside was somewhere taken for code, or for proof of identity. XSS is data taken for markup. CSRF is someone else's request taken for yours, because the browser attached the cookie on its own. A forged JWT is a payload taken as truth without verifying the signature. Learn that shape once and you recognise it again in SQL injection, in pickle deserialization, and in template injection.
The Python-specific part is counter-intuitive — the frameworks close most of the holes by default, and it is the developer who switches the protection off by hand. Django escapes {{ value }} in every template, until someone writes mark_safe so "the markup renders". CsrfViewMiddleware sits in the default MIDDLEWARE, until someone adds @csrf_exempt to "fix" a failing AJAX call. PyJWT demands an explicit algorithms list, until someone feeds it the value from the incoming token's own header. So the question sounds like "what is XSS", while what is really probed is different — do you understand why escaping belongs on output, and why every output context needs its own escaping. The layers below take these mechanisms one at a time.
Topic map
- Authentication and authorization — who you are versus what you may do; the strict order of the two steps,
401versus403, and checking object ownership. - Cookies and state over HTTP —
Set-Cookie, scoping by domain and path, the Django session, and why the browser attaches the cookie by itself. - XSS — data taken for markup — stored, reflected and DOM-based; template autoescaping and picking the right tool per output context.
- Cookie flags and signing — what
HttpOnly,SecureandSameSiteactually do, why a CSRF token is still needed on top, and why signing is not encryption. - JWT — signed, not encrypted — three
base64urlsegments, thealg:noneandHMAC/RSAconfusion attacks, the price of revocation, and choosing browser storage.
Common mistakes and traps
| Mistake | Consequence |
|---|---|
Treating HttpOnly as encryption of the cookie value | The flag only removes the cookie from document.cookie; the value stays as readable as it was — on the wire, in devtools, in the browser profile |
Reading Secure as "the cookie does not reach the server" | Secure only forbids sending over plain HTTP; the server receives the cookie on every request — the whole session scheme depends on it |
| Confusing signing with encryption | HMAC gives integrity — the server detects tampering; it gives no confidentiality, and a signed cookie's contents or a JWT payload are readable by anyone holding them |
| Escaping on input instead of on output | The same string is safe in an HTML body and dangerous inside <script> or in an href; the required context is known only at the point of output |
Marking user data with mark_safe or the safe filter | Autoescaping is disabled for exactly the data it existed to protect — the most common way to reintroduce XSS into a secure-by-default project |
Checking is_authenticated and then fetching the object by pk from the URL | The request is authenticated but not authorized — any logged-in user reads someone else's object by substituting another pk |
Trusting the alg field from the incoming token's header | The attacker picks the verification algorithm — hence alg:none and HS256 signed with the RSA public key |
Assuming a JWT can be revoked instantly | The token stays valid until exp for anyone holding it; revocation needs server state — a jti denylist, a token version, or short-lived access tokens |
What interviews check
The topic almost always comes as a three-rung ladder, and each rung probes a mechanism rather than a term. A junior is asked the difference between authentication and authorization, and what a cookie and XSS are — what is wanted is not the definition but the correct order ("who first, then what is allowed"), plus the understanding that a cookie lives in the browser rather than on the server and that XSS runs for every viewer of the page. A middle is asked how to protect a cookie and what a JWT is. Failure here comes not from forgetting the flags but from a wrong model — a great many people are convinced that HttpOnly encrypts the value and that a signature makes the payload secret. The single sentence "signing gives integrity, not confidentiality" closes both questions at once.
The senior questions are XSS defence and JWT pitfalls, and both are about defence in depth. On XSS, the accepted answer ties escaping to the output context, sanitizes with a vetted library, and names CSP and HttpOnly as the second line, not the fix. "I will cap the field length" and "we are on HTTPS" fail the question outright. On JWT the expected three points are that secrets do not belong in the payload, that the server pins the expected alg, and that revocation costs state. The most common mistake at this level is talking about JWT as a strict improvement over sessions without naming what statelessness was paid for. A good answer sounds like a trade-off, not like an advertisement.