Django Security: Common Vulnerabilities and Mitigations

1. SQL Injection (SQLi)

SQL Injection is an attack where a malicious user inserts, or "injects," SQL code into an application's input fields. If the application isn't careful, this injected code can be executed by the database, allowing the attacker to bypass authentication, steal data, modify data, or even destroy it.

The Attack Flow

Imagine a simple query that retrieves a user's data, constructed by concatenating strings:

# VULNERABLE CODE - DO NOT USE
username = request.GET.get('username')
sql_query = "SELECT * FROM users WHERE username = '" + username + "';"
# cursor.execute(sql_query)

An honest user would provide their username, say arun. The query becomes SELECT * FROM users WHERE username = 'arun';.

However, an attacker could provide the input admin' OR '1'='1. The resulting query becomes:

SELECT * FROM users WHERE username = 'admin' OR '1'='1';

Since '1'='1' is always true, the WHERE clause evaluates to true for every single row in the users table, potentially exposing all user data to the attacker.

Django's Primary Defense: The ORM

The single most important security feature Django provides against SQLi is its Object-Relational Mapper (ORM). When you write a query like User.objects.get(username=some_variable), Django does not simply mash strings together. Instead, it uses parameterized queries (also called prepared statements).

To understand this concept, which is fundamental to database security, please watch the following video.

In essence, the ORM tells the database, "Here is the query I want to run, and it has one placeholder for a username. Now, here is the value for that placeholder." The database engine treats the value as literal data, never as executable SQL, completely neutralizing the threat.

The Pitfall: Raw SQL Queries

The main way to become vulnerable to SQLi in a Django application is to bypass the ORM and write raw SQL queries incorrectly.

As the article highlights, if you absolutely must use raw SQL, you must still use parameterization.

• Wrong (Vulnerable): cursor.execute("SELECT * FROM users WHERE username = '%s';" % username)
• Correct (Safe): cursor.execute("SELECT * FROM users WHERE username = %s;", [username])

By passing the parameters as a separate list, you allow the database driver to safely escape the values and prevent injection, preserving the security benefits of a prepared statement.

2. Cross-Site Scripting (XSS)

Cross-Site Scripting is an attack where a malicious user injects client-side scripts (usually JavaScript) into a web page that will be viewed by other users. When an unsuspecting user visits the page, the malicious script executes in their browser, with full access to that page. This can be used to steal session cookies, deface websites, or redirect users to malicious sites.

The Attack Flow

Consider a blog where users can post comments.

1. An attacker submits a comment containing a malicious script: <script>alert('Your session has been stolen!');</script>.
2. The server stores this "comment" in the database.
3. Later, another user (perhaps an admin) views the comment section.
4. The application retrieves the malicious comment from the database and embeds it directly into the HTML page.
5. The victim's browser sees the <script> tag and executes the JavaScript inside it.

Django's Primary Defense: Auto-Escaping

By default, the Django template engine protects you from XSS. It automatically escapes any variable's content before rendering it. This means it converts special HTML characters into their safe entity equivalents:

• < becomes <
• > becomes >
• " becomes "
• ' becomes '
• & becomes &

So, the attacker's malicious comment is rendered in the HTML as <script>alert('Your session has been stolen!');</script>. The browser displays this as literal text on the screen; it does not interpret it as a command to execute a script.

The Pitfall: The safe Filter

The most common way to create an XSS vulnerability in Django is by explicitly telling the template engine not to escape content using the |safe filter.

If you need to allow users to submit rich text (like bold or italic tags), using |safe is the wrong approach. The correct method is to use a sanitization library (like bleach) to clean the user's input before saving it to the database. This library will strip out dangerous tags (<script>, <iframe>) and attributes (onclick) while allowing a safe subset of HTML.

3. Cross-Site Request Forgery (CSRF)

A CSRF attack tricks an authenticated user into unknowingly submitting a malicious request to a web application they are logged into. It exploits the trust a site has in a user's browser, which automatically sends credentials like session cookies with every request to a given domain.

To fully grasp this, it's helpful to first review how cookies are used to maintain a login session.

Django's Primary Defense: The CSRF Token

As you saw in the video, the solution is to require a secret, unpredictable value in the request that an attacker's site cannot know. Django implements this via CSRF tokens.

Here's how it works:

1. The CsrfViewMiddleware (enabled by default in new Django projects) intercepts responses.
2. When you use the {% csrf_token %} template tag in a form, Django generates a unique, secret token and embeds it as a hidden input field. This token is tied to the user's session.
3. When the user submits the form (via a state-changing method like POST), the browser sends the form data along with the CSRF token.
4. The CsrfViewMiddleware intercepts the incoming request, extracts the token, and verifies that it matches the one it expects for that user's session.
5. If the tokens match, the request is allowed to proceed. If they don't match or the token is missing, Django rejects the request with a 403 Forbidden error.

Since an attacker on a different domain (evil.com) has no way of knowing the user's CSRF token for your-app.com, any forged request they trick the user into sending will be missing the valid token and will be blocked.

Conclusion

In this lesson, we've taken a tour of three foundational web security vulnerabilities. You now have a solid conceptual understanding of what they are and, more importantly, how Django's architecture provides robust, default protection against them.

Key Takeaways:

• SQL Injection (SQLi) is prevented by using Django's ORM, which employs parameterized queries. The biggest risk is using raw SQL with unsafe string formatting.
• Cross-Site Scripting (XSS) is mitigated by the Django template engine's default HTML auto-escaping. The biggest risk is using the |safe filter or manually generating HTML in views.
• Cross-Site Request Forgery (CSRF) is stopped by Django's CSRF token mechanism, which validates that state-changing requests originate from your own site. The biggest risk is forgetting to use {% csrf_token %} in forms or disabling the middleware.
• The common theme is that Django's "batteries-included" philosophy extends to security. Your primary job is to understand these protections so you don't inadvertently disable them.

Preview of the Next Lesson:
We will continue our exploration of web security by looking at a mechanism that governs how different websites are allowed to interact with each other. In the next lesson, we will implement Cross-Origin Resource Sharing (CORS) policies to control browser access to the API, a crucial step for securing modern web applications.