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.