For some time now I've been working on a new project with the idea that you want to use a single testing tool that can give you comprehensive, coherent, and deep advice. It's early days and there's a lot to add still, but even now it's pretty good: https://www.hardenize.com
Hardenize starts with the ___domain name (WHOIS), then DNS/DNSSEC/CAA, then email configuration (SMTP/STARTTLS/DANE/SPF/DMARC), then your web application (TLS/COOKIES/HSTS/HPKP/CSP/various headers, etc).
This sounds very interesting for budding platform developers.
One problem is testing the more bespoke vuln routes - that's to say, the buffer overflows, the old package exploits, the strange oddities. By the sounds of it, you are building an "obvious security pitfalls" testing bot, which is in itself very valuable don't get me wrong, but i'm pushed to say that it's an NP problem to test bespoke vuln routes, which means the kind of testing process you are developing (linear-time problem solver) will struggle with testing the non-linear-time problems of bespoke vulns.
However, I wish you luck, hats off to this, it's a great idea!
My goal is to promote good engineering and security practices, and to make it easy to adopt them and deploy them correctly. I feel that's one area that doesn't get enough attention. At the same time, it's the only direction that will actually improve things in the long run. Chasing vulnerabilities is a fact of life, but even if you could eradicate them from your software today, you're not going to be safer tomorrow.
To that end, Hardenize doesn't check for vulnerabilities. There's plenty of existing tools that do; I don't want to reinvent that wheel.
Ivanr this is an excellent resource (just like SSL Labs) but I'm missing the "gamification" element: percentage points that make one strive for 100% (whether it is a good idea is a separate matter).
Regarding DANE is there a benefit in deploying it now that browser vendors are against it?
Also worth noting is that Key Pinning may be a very sharp knife.
If you don't return any CORS headers, all cross-origin requests will be blocked by default. If that's the behavior you want, there is no need to return any CORS headers.
It's cross-origin, and it's a request, cookies will be sent with it, and if your GET requests have side-effects, you're going to have a bad time. You can even do POST requests, by making a <form> and auto-submitting it to the API with JavaScript. Of course, you're limited to certain MIME types, and notably not JSON. (And thank God for that.)
Even if we assume that you only meant requests made by JavaScript via XHR, you can still make cross-origin requests. If you make an XHR request that looks like any of the above (specifically, if it meets the criteria for a "Simple Request"[1]), the browser will send it. It might not allow the JS that sent the request to view the response (if the response doesn't have the appropriate CORS headers), but the request still gets sent (because the response has to get received), and any side-effects can still happen.
Thankfully, if you're writing a bog-standard JSON API, these usually don't apply … as long as you check your Content-Type header prior to decoding as JSON.
(You are completely right, I think, that not returning any CORS headers is the most restricted — as far as CORS is concerned. My point being that sometimes, it's the response that gets blocked, not so much the request.)
You're right, it's the response not the request that gets blocked.
What's even worse, modern browsers will make an OPTIONS "preflight request" if you try to make a non-simple cross-origin request with XHR, whether with or without CORS. The actual GET or POST request might be blocked, but OPTIONS always goes through. So if your webapp doesn't distinguish between GET and OPTIONS, and if your GET actions have side effects, you're in for a nasty surprise!
Mozilla had an excellent resource [0] for security headers, especially Content Security Policy with examples for different use cases (e.g. APIs).
See also Google's CSP Evaluator [1] and a blog post outlining security best practices [2]. It's surprisingly easy to make insecure policy that on the surface looks good, usually due to JSON-P endpoints on foreign endpoints.
I think `X-XSS-Protection: 1; mode=block` is enabled by default in Chrome for all sites. I remember sending a malicious payload to one of my own pages and having the entire page blocked by Chrome (but not by Firefox).
I thought the same and I don't think there's a downside. I've been setting SameSite=strict for the session cookie in a B2B app for about a year and no one has complained. It's silently ignored by IE10 and Firefox, at least.
Hardenize starts with the ___domain name (WHOIS), then DNS/DNSSEC/CAA, then email configuration (SMTP/STARTTLS/DANE/SPF/DMARC), then your web application (TLS/COOKIES/HSTS/HPKP/CSP/various headers, etc).
Before Hardenize, I built SSL Labs.