Clickjacking protection in Django - Step-by-Step Execution

Concept Flow - Clickjacking protection

User sends request to Django app

↓

Django processes request

↓

Middleware adds X-Frame-Options header

↓

Response sent with header

↓

Browser checks X-Frame-Options

↓

Block framing

↓

User safe from clickjacking

Django adds a special header to responses that tells browsers if the page can be shown inside frames, blocking clickjacking attacks.

Execution Sample

Django

MIDDLEWARE = [
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

# In views.py
from django.http import HttpResponse
from django.views.decorators.clickjacking import xframe_options_deny

@xframe_options_deny
def my_view(request):
    return HttpResponse('Safe content')

This code enables Django's clickjacking protection middleware and uses a decorator to deny framing on a specific view.

Execution Table

Step	Action	Middleware Header Added	Response Header X-Frame-Options	Browser Behavior
1	Request received by Django app	No	None	Browser waits for response
2	Django processes request and calls view	No	None	Browser waits for response
3	View returns HttpResponse	No	None	Browser waits for response
4	XFrameOptionsMiddleware adds header	Yes	DENY	Browser receives response with header
5	Response sent to browser	Yes	DENY	Browser checks header
6	Browser blocks page from being framed	Yes	DENY	Clickjacking prevented
7	If no header or ALLOW, browser allows framing	No or ALLOW	ALLOW or None	Clickjacking possible

💡 Execution stops after response is sent and browser enforces X-Frame-Options header.

Variable Tracker

Variable	Start	After Step 3	After Step 4	Final
X-Frame-Options Header	None	None	DENY	DENY
Response Object	None	HttpResponse('Safe content')	HttpResponse with header	HttpResponse with header

Key Moments - 3 Insights

Why does the X-Frame-Options header appear only after middleware runs?

Because the middleware adds the header after the view returns the response, as shown in execution_table step 4.

What happens if the header is missing or set to ALLOW?

The browser will allow the page to be framed, which can enable clickjacking, as shown in execution_table step 7.

How does the decorator @xframe_options_deny affect the response?

It sets the X-Frame-Options header to DENY for that view's response, ensuring clickjacking protection, reflected in the header value in step 4.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the X-Frame-Options header get added?

A Step 4

B Step 2

C Step 1

D Step 7

💡 Hint

Check the 'Middleware Header Added' column in the execution_table.

According to variable_tracker, what is the value of the X-Frame-Options header after step 4?

A None

B DENY

C ALLOW

D SAMEORIGIN

💡 Hint

Look at the 'After Step 4' column for 'X-Frame-Options Header' in variable_tracker.

If the middleware was removed, what would happen to clickjacking protection according to the execution table?

A Protection would still work

B Browser would block framing anyway

C No header added, so clickjacking possible

D Response would fail to send

💡 Hint

Refer to execution_table step 7 about missing header effects.

Concept Snapshot

Clickjacking protection in Django:
- Use XFrameOptionsMiddleware in MIDDLEWARE settings
- Middleware adds X-Frame-Options header to responses
- Header values: DENY, SAMEORIGIN block framing
- Use @xframe_options_deny decorator for per-view control
- Browser blocks framing if header denies it
- Prevents malicious overlay attacks

Full Transcript

Clickjacking protection in Django works by adding a special HTTP header called X-Frame-Options to responses. This header tells the browser whether the page can be shown inside a frame or iframe. Django provides middleware called XFrameOptionsMiddleware that automatically adds this header to all responses. You can also use decorators like @xframe_options_deny on views to set this header per view. When the browser sees the header set to DENY or SAMEORIGIN, it blocks the page from being framed by other sites. This stops attackers from tricking users into clicking hidden buttons or links, protecting against clickjacking attacks. The execution flow starts with the user request, then Django processes it, the middleware adds the header, and finally the browser enforces the protection when rendering the page.

Practice

1. What is the main purpose of Django's clickjacking protection?

easy

A. To speed up page loading times

B. To encrypt user data on the server

C. To prevent other websites from embedding your pages in frames

D. To improve SEO rankings

Solution

1. Step 1: Understand clickjacking risks

   Clickjacking happens when a site is embedded in a hidden frame to trick users into clicking.

2. Step 2: Identify Django's protection goal

   Django adds headers to stop other sites from embedding your pages in frames.

3. Final Answer:

   To prevent other websites from embedding your pages in frames -> Option C

4. Quick Check:

   Clickjacking protection = prevent framing [OK]

Hint: Clickjacking protection blocks framing by other sites [OK]

Common Mistakes:

• Confusing clickjacking with data encryption
• Thinking it speeds up page load
• Assuming it improves SEO

2. Which Django middleware is used to enable clickjacking protection by default?

easy

A. django.middleware.clickjacking.XFrameOptionsMiddleware

B. django.middleware.security.SecurityMiddleware

C. django.middleware.common.CommonMiddleware

D. django.middleware.csrf.CsrfViewMiddleware

Solution

1. Step 1: Recall Django middleware for clickjacking

   Django provides a specific middleware named XFrameOptionsMiddleware for clickjacking protection.

2. Step 2: Match middleware to function

   SecurityMiddleware handles security headers but not framing; CommonMiddleware and CsrfViewMiddleware serve other purposes.

3. Final Answer:

   django.middleware.clickjacking.XFrameOptionsMiddleware -> Option A

4. Quick Check:

   XFrameOptionsMiddleware = clickjacking protection [OK]

Hint: XFrameOptionsMiddleware controls frame options header [OK]

Common Mistakes:

• Choosing SecurityMiddleware for clickjacking
• Confusing CSRF middleware with clickjacking
• Selecting CommonMiddleware incorrectly

3. What HTTP header does Django's clickjacking protection middleware add to responses?

medium

A. Content-Security-Policy

B. X-Frame-Options

C. Strict-Transport-Security

D. X-Content-Type-Options

Solution

1. Step 1: Identify header related to framing

   The header that controls whether a page can be framed is X-Frame-Options.

2. Step 2: Match header to Django middleware

   Django's clickjacking middleware adds X-Frame-Options to block framing by other sites.

3. Final Answer:

   X-Frame-Options -> Option B

4. Quick Check:

   Clickjacking header = X-Frame-Options [OK]

Hint: X-Frame-Options header blocks framing [OK]

Common Mistakes:

• Confusing with Content-Security-Policy header
• Mixing with Strict-Transport-Security
• Choosing unrelated security headers

4. You added @xframe_options_exempt decorator to a view but clickjacking protection still blocks framing. What is the likely cause?

medium

A. The decorator disables CSRF protection, causing conflict

B. You forgot to add XFrameOptionsMiddleware in settings

C. You must also set X_FRAME_OPTIONS = None in settings

D. The decorator only works if middleware is enabled

Solution

1. Step 1: Understand decorator dependency

   The @xframe_options_exempt decorator only works if the XFrameOptionsMiddleware is active.

2. Step 2: Identify cause of blocking

   If middleware is missing or disabled, the decorator has no effect; if middleware is enabled, decorator exempts the view.

3. Final Answer:

   The decorator only works if middleware is enabled -> Option D

4. Quick Check:

   Decorator needs middleware enabled [OK]

Hint: Decorator requires middleware to function [OK]

Common Mistakes:

• Assuming decorator works without middleware
• Thinking CSRF relates to clickjacking decorator
• Trying to disable header via settings incorrectly

5. You want to allow framing only from your own domain 'example.com' but block all others. How do you configure Django's clickjacking protection?

hard

A. Set X_FRAME_OPTIONS = 'SAMEORIGIN' and serve from example.com domain

B. Use @xframe_options_exempt on all views and add custom header manually

C. Set X_FRAME_OPTIONS = 'DENY' in settings.py

D. Set X_FRAME_OPTIONS = 'ALLOW-FROM https://example.com' in settings.py

Solution

1. Step 1: Understand X-Frame-Options values

   'DENY' blocks all framing; 'SAMEORIGIN' allows framing from same domain; 'ALLOW-FROM' is deprecated and not widely supported.

2. Step 2: Choose best practical option

   Serving your site from example.com and setting 'SAMEORIGIN' allows framing only from your domain.

3. Final Answer:

   Set X_FRAME_OPTIONS = 'SAMEORIGIN' and serve from example.com domain -> Option A

4. Quick Check:

   SAMEORIGIN allows framing from own domain [OK]

Hint: Use SAMEORIGIN to allow framing from your domain only [OK]

Common Mistakes:

• Using DENY which blocks all framing including own domain
• Using ALLOW-FROM which is deprecated
• Exempting views unnecessarily