SQL Injection Protection
SQL injection is a type of attack where a malicious user is able to execute arbitrary SQL code on a database. This can result in records being deleted or data leakage.
By using Django’s querysets, the resulting SQL will be properly escaped by the underlying database driver. However, Django also gives developers power to write raw queries or execute custom sql. These capabilities should be used sparingly and you should always be careful to properly escape any parameters that the user can control. In addition, you should exercise caution when using
Clickjacking is a type of attack where a malicious site wraps another site in a frame. This type of attack occurs when a malicious site tricks a user into clicking on a concealed element of another site which they have loaded in a hidden frame or iframe.
Django contains clickjacking protection in the form of the
X-Frame-Options middleware which in a supporting browser can prevent a site from being rendered inside a frame. It is possible to disable the protection on a per view basis or to configure the exact header value sent.
The middleware is strongly recommended for any site that does not need to have its pages wrapped in a frame by third party sites, or only needs to allow that for a small section of the site.
An Example of Clickjacking
Suppose an online store has a page where a logged in user can click “Buy Now” to purchase an item. A user has chosen to stay logged into the store all the time for convenience. An attacker site might create an “I Like Ponies” button on one of their own pages, and load the store’s page in a transparent
iframe such that the “Buy Now” button is invisibly overlaid on the “I Like Ponies” button. If the user visits the attacker’s site, clicking “I Like Ponies” will cause an inadvertent click on the “Buy Now” button and an unknowing purchase of the item.
Modern browsers honor the X-Frame-Options HTTP header that indicates whether or not a resource is allowed to load within a frame or iframe. If the response contains the header with a value of
SAMEORIGIN then the browser will only load the resource in a frame if the request originated from the same site. If the header is set to
DENY then the browser will block the resource from loading in a frame no matter which site made the request.
Django provides a few simple ways to include this header in responses from your site:
- A simple middleware that sets the header in all responses.
- A set of view decorators that can be used to override the middleware or to only set the header for certain views.
How to Use It
Setting X-Frame-Options for All Responses
To set the same
X-Frame-Options value for all responses in your site, put
This middleware is enabled in the settings file generated by
By default, the middleware will set the
X-Frame-Options header to
SAMEORIGIN for every outgoing
HttpResponse. If you want
DENY instead, set the
When using the middleware there may be some views where you do not want the
X-Frame-Options header set. For those cases, you can use a view decorator that tells the middleware not to set the header:
Setting X-Frame-Options Per View
To set the
X-Frame-Options header on a per view basis, Django provides these decorators:
Note that you can use the decorators in conjunction with the middleware. Use of a decorator overrides the middleware.
X-Frame-Options header will only protect against clickjacking in a modern browser.
Older browsers will quietly ignore the header and need other clickjacking prevention techniques.
Browsers That Support X-Frame-Options
- Internet Explorer 8+
- Firefox 3.6.9+
- Opera 10.5+
- Safari 4+
- Chrome 4.1+