(I'm still new to this and I don't know how to format this properly so it looks neat, sorry about that)
I'm trying to modify my Browser Headers but they don't seem to be changing, when checking the headers with http://ip-check.info they do show up, but when checking the headers using the Developer Tools, they're the same as before? I'm using Firefox 40.0.
Example (Facebook) :
Content-Security-Policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net .google.com 127.0.0.1: .spotilocal.com: 'unsafe-inline' 'unsafe-eval' *.akamaihd.net *.atlassolutions.com blob:;style-src * 'unsafe-inline';connect-src *.facebook.com *.fbcdn.net *.facebook.net .spotilocal.com: .akamaihd.net wss://.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com;
Strict-Transport-Security: max-age=15552000; preload
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 0
I would like to modify the headers to this:
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-WebKit-CSP: default-src 'self'
X-Content-Security-Policy: default-src 'self'
Content-Security-Policy: default-src 'self'
I have tried using these two Add-Ons (not at the same time) :
https://addons.mozilla.org/en-US/firefox/addon/modify-headers
https://addons.mozilla.org/en-US/firefox/addon/modify-header-value
Related
A few months ago, I added security headers to all of the pages on my website. The Mozilla Observatory detected the changes then and the score increased to B+. Though I haven't changed a thing, it now tells me there are none and I get a F score. That being said, both in Chrome and in Firefox, I do see the headers. What's wrong ? Any help is appreciated.
Here are the response headers :
cache-control: no-store, no-cache, must-revalidate
content-encoding: gzip
content-language: fr
content-security-policy: default-src 'self'; style-src 'self' 'unsafe-inline'; script-src https://mydomain/config.js 'unsafe-inline'; form-action 'self'; frame-ancestors 'none';
content-type: text/html; charset=UTF-8
date: Sun, 17 Oct 2021 11:41:27 GMT
expect-ct: enforce,max-age=2592000
expires: Thu, 19 Nov 1981 08:52:00 GMT
pragma: no-cache
referrer-policy: strict-origin
server: Apache
strict-transport-security: max-age=15768000 ; includeSubDomains ;
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 1;mode=block
Edit : Here is the result of the analysis
Analysis returned by the Mozilla observatory
I was having the same problem with X-XSS in Mozilla Observatory and found this:
<IfModule mod_headers.c>
Header always set X-XSS-Protection "1; mode=block"
</IfModule>
Then, the Observatory validated properly.
I've inherited a web-app hosted in Azure and it appears the staging environment CORS is not functioning like all other environments.
I'm fairly new to Azure administration and I've applied the CORS configuration on the API app service (previously had no config set) which did not resolve the issue.
You can compare the different environment general/response headers below.
Local Dev...
Request URL: http://localhost:3001/api/getstarted/plans?fetchExcluded=true
Request Method: GET
Status Code: 200 OK
Remote Address: [::1]:3001
Referrer Policy: strict-origin-when-cross-origin
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Encoding: gzip
Content-Type: application/json; charset=utf-8
Date: Thu, 04 Nov 2021 21:55:22 GMT
Keep-Alive: timeout=5
Strict-Transport-Security: max-age=15552000; includeSubDomains
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Current Production...
Request URL: https://api.<webapp>.app/api/getstarted/plans?fetchExcluded=true
Request Method: OPTIONS
Status Code: 204 No Content
Remote Address: ##.###.###.###:443
Referrer Policy: strict-origin-when-cross-origin
Access-Control-Allow-Headers: authorization
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
Access-Control-Allow-Origin: *
Date: Thu, 04 Nov 2021 22:04:19 GMT
Strict-Transport-Security: max-age=15552000; includeSubDomains
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
However in staging...
Request URL: https://<webapp>.azurewebsites.net/api/getstarted/plans?fetchExcluded=true
Request Method: OPTIONS
Status Code: 503 Service Temporarily Unavailable
Remote Address: ##.###.###.###:443
Referrer Policy: strict-origin-when-cross-origin
Content-Length: 398
Date: Thu, 04 Nov 2021 21:56:02 GMT
Server: nginx
and from debug console in staging...
- Access to XMLHttpRequest at
'https://<webapp>.azurewebsites.net/api/getstarted/plans?fetchExcluded=true'
from origin 'https://<webapp>.z8.web.core.windows.net' has been
blocked by CORS policy: Response to preflight request doesn't pass
access control check: No 'Access-Control-Allow-Origin' header is
present on the requested resource. xhr.js:178
- GET
https://<webapp>-api-staging.azurewebsites.net/api/getstarted/plans?fetchExcluded=true
net::ERR_FAILED
I've checked the Azure Subscription usage + quotas, and the only thing nearing quota is "Network Watchers"
The API framework is ExpressJS with CORS...
app.use(cors())
In my opinion the issue has nothing to do with CORS, well, better said,...
As you can see in the staging environment you are receiving a 503, service unavailable, HTTP status error code:
Status Code: 503 Service Temporarily Unavailable
So my guess is that the staging environment is not working properly by some reason, and the associated load balancer is returning a 503 error page, of course, without any CORS indication, and your browser is complaining due to the fact your API doesn't receive a valid response.
Please, review the status of the staging environment: once healthy, it probably will offer a proper response to your application.
Unfortunately the issue was not CORS at all; rather the server image was failing to build and compile due to ESNext JS syntax (server < ESNext)
I found the logstream API which allowed me to view all errors, for posterity you might be able to find the same; https://<webapp>.scm.azurewebsites.net/api/logstream
I am building a node express rest app with react frontend. At development the backend is running at localhost:5000 and the frontend at localhost:3000. I am using session based authentication system. So I am sending a Set-Cookie header when authentication is successful from the backend. But the problem is that since the frontend and the backend area on different domains the cookie cannot be set.
What can be done?
Plus, I do not want to use the JWT for authentication for the reasons laid out at http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
Middleware
const cors = require('cors');
app.use(cors({ credentials: true, origin: 'http://localhost:3000' }));
Following is the header sent back from the backend
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 129
Content-Type: application/json; charset=utf-8
Date: Sun, 22 Dec 2019 14:24:03 GMT
ETag: W/"81-RZ35EekMxvCHWWNZ8hxPVFlS+R8"
Set-Cookie: connect.sid=s%3Afa5CxZSLQznDHuO7I6y9qAfy5-VuezUj.I%2F3BP6vfXybkyUXej6%2Fjt5ribqmmfoy1NQfSImuNYaU; Path=/; Expires=Sun, 29 Dec 2019 14:24:03 GMT; HttpOnly
Strict-Transport-Security: max-age=15552000; includeSubDomains
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
I have a server which returns a different response based on the Accept header e.g. if Accept header includes "image/webp", a webp image is served, otherwise a jpg is served.
We run Varnish at server-level and it does this correctly, as per example below:
Request (with image/webp in Accept header):
curl -s -D - -o /dev/null "https://REDACTED/media/tokinoha_bowl-4.jpg?sh=2&fmt=webp,jpg" -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8"
Response (webp image served):
HTTP/2 200
date: Wed, 06 Feb 2019 08:25:05 GMT
content-type: image/webp
access-control-allow-origin: *
cache-control: public, s-maxage=31536000, max-age=31536000
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
strict-transport-security: max-age=31536000; includeSubDomains
vary: Accept-Encoding, Accept-Encoding,Origin
referrer-policy: strict-origin-when-cross-origin
accept-ranges: bytes
content-length: 60028
Request (no webp in Accept header, jpg served):
curl -s -D - -o /dev/null "https://REDACTED/media/tokinoha_bowl-4.jpg?sh=2&fmt=webp,jpg" -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/apng,*/*;q=0.8"
Response:
HTTP/2 200
date: Wed, 06 Feb 2019 08:25:18 GMT
content-type: image/jpeg
access-control-allow-origin: *
cache-control: public, s-maxage=31536000, max-age=31536000
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
strict-transport-security: max-age=31536000; includeSubDomains
vary: Accept-Encoding, Accept-Encoding,Origin
referrer-policy: strict-origin-when-cross-origin
accept-ranges: bytes
content-length: 166991
We have the below options in the Rules Engine set up, however whichever content-type is cached first is served on all subsequent requests irrespective of request header.
Rules Engine settings
Does anyone know of a way to achieve this?
Thanks in advance!
We had the same problem with Verizon/Edgecast: One URL delivered two different image types (JPEG and WebP) depending on Accept header. The origin (imgix) sent correctly Vary: Accept, but Edgecast ignored that and cached what it get and so browsers without WebP support got sometimes the wrong format.
We solved it with a rule in Edgecast:
WebP rule
The query parameter auto is always part of the URL and can therefore always be removed from the cache key. With the second query parameter varyWebP we recognize the URLs definitely and prevent a collision with URLs without query parameter auto.
In this case the URL
https://[HOST]/[PATH]?a=1&b=2&c=3&auto=compress,format
creates the same cache key as:
https://[HOST]/[PATH]?a=1&b=2&c=3
That's why the query parameter varyWebP protects us.
Why do we get the below 2 headers while trying to read files stored in Azure Data Lake using REST API?
Cache-Control →no-cache, no-cache, no-store, max-age=0 (Why do we have multiple no-cache)
Pragma →no-cache
Why are these Headers getting set and How can we override them such them we can cache the responses ?
Below is my curl request
curl -v -X GET -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlJyUXF1OXJ5ZEJWUldtY29jdVhVYjIwSEdSTSIsImtpZCI6IlJyUXF1OXJ5ZEJWUldtY29jdVhVYjIwSEdSTSJ9.eyJhdWQiOiJodHRwczovL21hbmFnZW1lbnQuY29yZS53aW5kb3dzLm5ldC8iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC8wNmZhNTQ1Yy01MmQ3LTRiOGMtYjBmNy03MzQ5MTFiNDA0MmEvIiwiaWF0IjoxNDgxMTc3MTE3LCJuYmYiOjE0ODExNzcxMTcsImV4cCI6MTQ4MTE4MTAxNywiYXBwaWQiOiI3MzU0NDBhNy1kM2RmLTQ0YjEtYTk2Yy0wMTlhMzE5NmEwYmYiLCJhcHBpZGFjciI6IjEiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC8wNmZhNTQ1Yy01MmQ3LTRiOGMtYjBmNy03MzQ5MTFiNDA0MmEvIiwib2lkIjoiNTM4OTQyMjQtNDIyNC00MTllLTgxNzAtMzQ3NTQwNGI2NGFlIiwic3ViIjoiNTM4OTQyMjQtNDIyNC00MTllLTgxNzAtMzQ3NTQwNGI2NGFlIiwidGlkIjoiMDZmYTU0NWMtNTJkNy00YjhjLWIwZjctNzM0OTExYjQwNDJhIiwidmVyIjoiMS4wIn0.TrkCayxF0MJbXe7SPc8ZtMx8Aw07Plv0PE1KDAUw1hjHBgmTE95y0ivA2qKpmkvbLkreaGICmzc-4DPNcPBgQFHaiHzS9MoiC6c0mOO_0oOw7FRsbDYnL-P03_MEoHYDas7o2BC88ruZlHHePmoOHqwwXwBOgr6si5RwRmFz7InJpfILqENKD-fk2uWBWfQ1JU3xvmVLUgeoToFK-q7Xs
g6eHgW84S4gGF7xuvjz2ogduxmhaV18A80rFFRFk70uHXllFcDylHKXPqgRJ9dfHswZEczxQSQCI2hH5XTn72xMUI0ygIFX4mPjwPQhxPAaygMLxYBOhG5gNm1vBAsJww" "https://signstorage.azuredatalakestore.net/webhdfs/v1/signsdata/test.txt?op=OPEN&api-version=2016-11-01&read=true"
Response
File contents and Response Headers are
HTTP/1.1 200 OK
Cache-Control: no-cache, no-cache, no-store, max-age=0
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: application/octet-stream
Expires: -1
x-ms-request-id: 302fd601-0eca-4db0-a2de-cc2ee5d951d8
x-ms-webhdfs-version: 16.07.18.01
Status: 0x0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=15724800; includeSubDomains
Date: Thu, 08 Dec 2016 06:27:31 GMT
For security reasons, ADLS doesn't support caching mechanisms, hence the headers that you see are sent by the service to limit caching.
Thank you,
Guy