Menu
I've searched on this topic and can't find anything in the nginx configuration that says if this is "ok" or not?
This appears to work just fine, other than messing up the syntax highlighting in vim:
add_header Content-Security-Policy "default-src 'self' *.google-analytics.com;
object-src 'none';
report-uri /csp-report;";
But is it actually valid? Am I relying on browsers understanding line breaks inside a CSP, or does nginx render it into one line before serving it? Fiddler appears to show it as one line, but again I don't know if nginx is serving it as that or if Fiddler is interpreting it as that.
(This is obviously a much simplified version of my true CSP, which is certainly very much long enough that I consider it beneficial to my sanity to split it onto multiple lines!)
337
Nginx add_header allows us to define a value and an arbitrary response header is included in the code of the response. The nginx add_header is defined in the configuration file of nginx.
Search for syntax errors or warnings in the configuration Through a simple command you can verify the status of the Nginx configuration file: $ sudo systemctl config nginx The output will show if the configuration file is correct or, if it is not, it will show the file and the line where the problem is.
By default the file is named nginx. conf and for NGINX Plus is placed in the /etc/nginx directory. (For NGINX Open Source , the location depends on the package system used to install NGINX and the operating system.
The servers that Nginx proxies requests to are known as upstream servers. Nginx can proxy requests to servers that communicate using the http(s), FastCGI, SCGI, and uwsgi, or memcached protocols through separate sets of directives for each type of proxy.
You can use variable nesting like this, which still in the end creates a one liner:
set $SCRIPT "script-src 'self'";
set $SCRIPT "${SCRIPT} https://www.a.com"; # comment each line if you like
set $SCRIPT "${SCRIPT} https://b.com";
set $STYLE "style-src 'self'";
set $STYLE "${STYLE} https://a.com";
set $IMG "img-src 'self' data:";
set $IMG "${IMG} https://a.com";
set $IMG "${IMG} https://www.b.com";
set $FONT "font-src 'self' data:";
set $FONT "${FONT} https://a.com";
set $DEFAULT "default-src 'self'";
set $CONNECT "connect-src 'self'";
set $CONNECT "${CONNECT} https://www.a.com";
set $CONNECT "${CONNECT} https://www.b.com";
set $FRAME "frame-src 'self'";
set $FRAME "${FRAME} https://a.com";
set $FRAME "${FRAME} https://b.com";
add_header Content-Security-Policy "${SCRIPT}; ${STYLE}; ${IMG}; ${FONT}; ${DEFAULT}; ${CONNECT}; ${FRAME}";
Unfortunately, nginx treats the white space between the quotes literally, so as long as you begin each new line with a space or tab character, the header will remain valid.
However, it is possible to create an invalid header. For example, this produces an invalid header:
add_header Content-Security-Policy "default-src 'self' *.google-analytics.com;
object-src 'none';
report-uri /csp-report;";
The support for splitting header lines is deprecated in RFC 7230:
From RFC 7230 section 3.2.4
Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space
or horizontal tab (obs-fold). This specification deprecates such
line folding except within the message/http media type
The safest solution would be to accept that some lines in your configuration file may be very much longer than you would prefer.
37
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
