#30426: Make security headers default
-------------------------------------+-------------------------------------
Reporter: Adam (Chainz) | Owner: nobody
Johnson |
Type: New feature | Status: new
Component: Core (Other) | Version: 2.2
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Adam (Chainz) Johnson:
Old description:
> Following my security headers talk at DjangoCon Europe and its related
> blog post ( https://adamj.eu/tech/2019/04/10/how-to-score-a+-for-
> security-headers-on-your-django-website/ ), I'd like to make Django use
> more of these security headers by default on new projects. They're always
> harder to roll out on existing projects than to just bake in to the new
> project template.
>
> On current master, running `python manage.py check --deploy` on a fresh
> project created with `startproject` yields these warnings:
>
> ```
> System check identified some issues:
>
> WARNINGS:
> ?: (security.W004) You have not set a value for the SECURE_HSTS_SECONDS
> setting. If your entire site is served only over SSL, you may want to
> consider setting a value and enabling HTTP Strict Transport Security. Be
> sure to read the documentation first; enabling HSTS carelessly can cause
> serious, irreversible problems.
> ?: (security.W006) Your SECURE_CONTENT_TYPE_NOSNIFF setting is not set to
> True, so your pages will not be served with an 'X-Content-Type-Options:
> nosniff' header. You should consider enabling this header to prevent the
> browser from identifying content types incorrectly.
> ?: (security.W007) Your SECURE_BROWSER_XSS_FILTER setting is not set to
> True, so your pages will not be served with an 'X-XSS-Protection: 1;
> mode=block' header. You should consider enabling this header to activate
> the browser's XSS filtering and help prevent XSS attacks.
> ?: (security.W008) Your SECURE_SSL_REDIRECT setting is not set to True.
> Unless your site should be available over both SSL and non-SSL
> connections, you may want to either set this setting True or configure a
> load balancer or reverse-proxy server to redirect all connections to
> HTTPS.
> ?: (security.W012) SESSION_COOKIE_SECURE is not set to True. Using a
> secure-only session cookie makes it more difficult for network traffic
> sniffers to hijack user sessions.
> ?: (security.W016) You have 'django.middleware.csrf.CsrfViewMiddleware'
> in your MIDDLEWARE, but you have not set CSRF_COOKIE_SECURE to True.
> Using a secure-only CSRF cookie makes it more difficult for network
> traffic sniffers to steal the CSRF token.
> ?: (security.W018) You should not have DEBUG set to True in deployment.
> ?: (security.W019) You have
> 'django.middleware.clickjacking.XFrameOptionsMiddleware' in your
> MIDDLEWARE, but X_FRAME_OPTIONS is not set to 'DENY'. The default is
> 'SAMEORIGIN', but unless there is a good reason for your site to serve
> other parts of itself in a frame, you should change it to 'DENY'.
> ?: (security.W020) ALLOWED_HOSTS must not be empty in deployment.
>
> System check identified 9 issues (0 silenced).
> ```
>
> Three of these come from security headers that we could activate by
> default in the settings `SECURE_CONTENT_TYPE_NOSNIFF`,
> `SECURE_BROWSER_XSS_FILTER`, and `X_FRAME_OPTIONS`.
>
> I'd like to propose making them default in the `startproject` settings
> and even changing their global defaults (through a deprecation period) so
> they are activated by default.
New description:
Following my security headers talk at DjangoCon Europe and its related
blog post ( https://adamj.eu/tech/2019/04/10/how-to-score-a+-for-security-
headers-on-your-django-website/ ), I'd like to make Django use more of
these security headers by default on new projects. They're always harder
to roll out on existing projects than to just bake in to the new project
template.
On current master, running `python manage.py check --deploy` on a fresh
project created with `startproject` yields these warnings:
{{{
System check identified some issues:
WARNINGS:
?: (security.W004) You have not set a value for the SECURE_HSTS_SECONDS
setting. If your entire site is served only over SSL, you may want to
consider setting a value and enabling HTTP Strict Transport Security. Be
sure to read the documentation first; enabling HSTS carelessly can cause
serious, irreversible problems.
?: (security.W006) Your SECURE_CONTENT_TYPE_NOSNIFF setting is not set to
True, so your pages will not be served with an 'X-Content-Type-Options:
nosniff' header. You should consider enabling this header to prevent the
browser from identifying content types incorrectly.
?: (security.W007) Your SECURE_BROWSER_XSS_FILTER setting is not set to
True, so your pages will not be served with an 'X-XSS-Protection: 1;
mode=block' header. You should consider enabling this header to activate
the browser's XSS filtering and help prevent XSS attacks.
?: (security.W008) Your SECURE_SSL_REDIRECT setting is not set to True.
Unless your site should be available over both SSL and non-SSL
connections, you may want to either set this setting True or configure a
load balancer or reverse-proxy server to redirect all connections to
HTTPS.
?: (security.W012) SESSION_COOKIE_SECURE is not set to True. Using a
secure-only session cookie makes it more difficult for network traffic
sniffers to hijack user sessions.
?: (security.W016) You have 'django.middleware.csrf.CsrfViewMiddleware' in
your MIDDLEWARE, but you have not set CSRF_COOKIE_SECURE to True. Using a
secure-only CSRF cookie makes it more difficult for network traffic
sniffers to steal the CSRF token.
?: (security.W018) You should not have DEBUG set to True in deployment.
?: (security.W019) You have
'django.middleware.clickjacking.XFrameOptionsMiddleware' in your
MIDDLEWARE, but X_FRAME_OPTIONS is not set to 'DENY'. The default is
'SAMEORIGIN', but unless there is a good reason for your site to serve
other parts of itself in a frame, you should change it to 'DENY'.
?: (security.W020) ALLOWED_HOSTS must not be empty in deployment.
System check identified 9 issues (0 silenced).
}}}
Three of these come from security headers that we could activate by
default in the settings `SECURE_CONTENT_TYPE_NOSNIFF`,
`SECURE_BROWSER_XSS_FILTER`, and `X_FRAME_OPTIONS`.
I'd like to propose making them default in the `startproject` settings and
even changing their global defaults (through a deprecation period) so they
are activated by default.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30426#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.a26578b5d485fbdcc430c17011fc0b83%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
