Trusted host middleware in FastAPI - Step-by-Step Execution

Concept Flow - Trusted host middleware

Request Received

↓

Check Host Header

↓

Is Host in Trusted List?

No→Reject Request (400)

Yes↓

Pass Request to App

↓

Response Sent

The middleware checks the request's Host header against a trusted list. If trusted, it passes the request to the app; otherwise, it rejects it.

Execution Sample

FastAPI

from fastapi import FastAPI
from starlette.middleware.trustedhost import TrustedHostMiddleware

app = FastAPI()
app.add_middleware(TrustedHostMiddleware, allowed_hosts=["example.com", "localhost"])

This code adds TrustedHostMiddleware to allow requests only from example.com and localhost.

Execution Table

Step	Request Host Header	Check Host in Allowed List	Action	Result
1	"example.com"	Yes	Pass to app	Request processed
2	"localhost"	Yes	Pass to app	Request processed
3	"malicious.com"	No	Reject request	400 Bad Request response
4	""	No	Reject request	400 Bad Request response

💡 Requests with hosts not in allowed_hosts are rejected with 400 Bad Request.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
request_host	None	"example.com"	"localhost"	"malicious.com"	""
allowed_hosts	["example.com", "localhost"]	["example.com", "localhost"]	["example.com", "localhost"]	["example.com", "localhost"]	["example.com", "localhost"]
host_allowed	False	True	True	False	False

Key Moments - 3 Insights

Why does the middleware reject requests with empty Host headers?

Because the empty string is not in the allowed_hosts list, as shown in execution_table step 4, so the middleware rejects it for safety.

What happens if the Host header matches exactly one of the allowed hosts?

The middleware passes the request to the app, as seen in steps 1 and 2 of the execution_table where 'example.com' and 'localhost' are allowed.

Can the allowed_hosts list contain wildcards or patterns?

No, allowed_hosts must be exact hostnames or IPs; the middleware checks exact matches as shown in the execution_table.

Visual Quiz - 3 Questions

Look at the execution table, what is the action taken when the Host header is "malicious.com"?

A Pass to app

B Reject request

C Redirect request

D Ignore Host header

💡 Hint

Check execution_table row 3 under 'Action' column.

At which step does the Host header check result in 'True' for host_allowed?

A Step 4

B Step 3

C Step 1

D None

💡 Hint

Look at variable_tracker row for 'host_allowed' at 'After Step 1' and 'After Step 2'.

If we add "malicious.com" to allowed_hosts, how would step 3 in the execution table change?

A Action would be 'Pass to app' and Result 'Request processed'

B Action would remain 'Reject request'

C Result would be '500 Internal Server Error'

D No change

💡 Hint

Consider how allowed_hosts affects 'host_allowed' and action in execution_table step 3.

Concept Snapshot

TrustedHostMiddleware checks the Host header of incoming requests.
It compares the Host to a list of allowed hosts.
If the Host is allowed, the request proceeds.
If not, the middleware rejects with 400 Bad Request.
Use it to protect your app from Host header attacks.

Full Transcript

Trusted host middleware in FastAPI checks the Host header of each incoming request. It compares this Host value to a list of allowed hosts you provide. If the Host matches one in the list, the middleware lets the request continue to your app. If it does not match, the middleware rejects the request with a 400 Bad Request response. This protects your app from requests pretending to come from untrusted hosts. The middleware works by intercepting requests, checking the Host header, and deciding to pass or reject based on your allowed hosts list.