Nginx Security Hardening and Rules

c0nw0nk nginx-forum at
Sun Oct 19 17:47:53 UTC 2014

I have come across that same page before the one that is interesting me
right now is based of mex's comment on Security in header responses.

# config to don't allow the browser to render the page inside an frame or
# and avoid clickjacking
# if you need to allow [i]frames, you can use SAMEORIGIN or even set an uri
with ALLOW-FROM uri

add_header X-Frame-Options SAMEORIGIN;
# when serving user-supplied content, include a X-Content-Type-Options:
nosniff header along with the Content-Type: header,
# to disable content-type sniffing on some browsers.
# currently suppoorted in IE > 8
# 'soon' on Firefox

add_header X-Content-Type-Options nosniff;
# This header enables the Cross-site scripting (XSS) filter built into most
recent web browsers.
# It's usually enabled by default anyway, so the role of this header is to
re-enable the filter for
# this particular website if it was disabled by the user.

add_header X-XSS-Protection "1; mode=block";
# with Content Security Policy (CSP) enabled(and a browser that supports
# you can tell the browser that it can only download content from the
domains you explicitly allow
# I need to change our application code so we can increase security by
disabling 'unsafe-inline' 'unsafe-eval'
# directives for css and js(if you have inline css or js, you will need to
keep it too).
# more:

add_header Content-Security-Policy "default-src 'self'; script-src 'self'
'unsafe-inline' 'unsafe-eval'; img-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self'; frame-src; object-src 'none'";

Posted at Nginx Forum:,254125,254143#msg-254143

More information about the nginx mailing list