Question 1

What is CSRF, and how is it different from XSS?

Accepted Answer

Cross-site request forgery makes a **user's browser send a request they did not intend**, to a site where they are already authenticated — exploiting the fact that browsers attach cookies automatically to requests for a domain, regardless of which site initiated them.

**The distinction from XSS**, which is the source of most confusion:

**XSS** is an attack on the **user's trust in your site** — the attacker runs code in your origin and can read responses.

**CSRF** is an attack on **your site's trust in the user's browser** — the attacker causes a request to be sent but **cannot read the response**, because the same-origin policy still applies.

That asymmetry defines what CSRF can do: it performs **actions** — transfer money, change an email address, delete a record, add an administrator — but it cannot exfiltrate the result.

**How an attack works.** A malicious page contains a form auto-submitted to your endpoint, or an image tag pointing at a state-changing URL. The user's browser sends it with their cookies attached, and your server sees an authenticated request.

**The defences, in order of importance:**

**The SameSite cookie attribute**, which tells the browser not to attach the cookie to cross-site requests. `Lax` is now the default in major browsers and blocks most CSRF automatically — **this changed the landscape substantially**, though it is not complete protection and should not be the only control.

**Anti-CSRF tokens.** A secret value, unique per session or request, included in the form and checked on the server. The attacker's page cannot read it because of the same-origin policy, so it cannot include it.

**Checking `Origin` and `Referer` headers**, as a secondary control.

**Requiring re-authentication** for sensitive operations.

**What is not a defence:** using POST alone, since a form can be auto-submitted; obscure URLs; and checking that the request came from a logged-in user, which is the entire premise of the attack.

**Crucially, XSS defeats CSRF protection entirely** — script running in your origin can read the token. So CSRF defences assume you do not have XSS.

Question 2

What is cross-site scripting (XSS)?

Accepted Answer

An attack where attacker-controlled content is executed as JavaScript in another user's browser, in the context of your site — which means it runs with that user's session, cookies and permissions.

Question 3

What are common security vulnerabilities in Django applications and how can I prevent them?

Accepted Answer

Django security vulnerabilities include XSS, SQL Injection, CSRF, and insecure direct object references. Prevent these by using Django's built-in protections and best practices.

Question 4

What does the SameSite cookie attribute do?

Accepted Answer

SameSite controls whether a cookie is sent on requests originating from a different site. It exists primarily to mitigate cross-site request forgery, where a malicious page causes your browser to

Question 5

What are the essential security best practices for Django applications?

Accepted Answer

Implementing Django security best practices is essential for protecting applications from vulnerabilities. Key practices include using HTTPS, securing settings, and validating user input.

Question 6

What is the difference between authentication and authorization?

Accepted Answer

Authentication establishes who someone is. Authorization determines what that identity is allowed to do. They are sequential: you cannot meaningfully decide permissions before you know the identity,

Question 7

What is a JWT, and when should you not use one?

Accepted Answer

A JSON Web Token is a signed, self-contained token carrying claims — typically who the user is and when the token expires — which a server can verify without a database lookup. That property is its

Related Questions