WTF is this bullshit ?

https://securityheaders.com/

Basiclly you get an "F" if you don't provide these headers.But there is NO obligation for any browser to follow these headers. And if it is an attacker with custom software there is no point at all.

It has a far less to do with the headers than the support they indicate. Some of it is client behavior, some of it indicates server functionality and handling.

That said, I've seen plenty of companies just throw the headers on and pretend like they're secure.

Eh, that website is buggy and doesn't properly work again unless you reload it. Kind of distracts from whatever crap they are trying to meet. Is this based on some Euro laws or something. Google.com gets a D. My websites get F's. Sounds like BS.

My sites are all https and up to date.

My website earns A+. Https is fine, but there's a lot more to do. Too bad for all the folks who still dick around e.g. with inlined shit for CSS and JS so that they can't easily roll out proper CSP.

Some of these headers is to tell a visitors browsers how to handle things.

So they are to protect hacks between different windows in the same browsers of an innocent victim.

For example, you have two site open.

One of them triggers calls to the other site. These headers are to the browser how to handle such calls and what not to allow.

Without them the browser might allow such calls to use cookies or other info from the real window, thereby allowing spoofed calls that look like valid calls.

@Voxera If my browser is not sandboxing that shit then I would get a different browser.

@Fast-Nop Heh, I will just install the appropriate plugin in wordpress...

<awaiting punishment for mentioning wordpress ;-)>

Well google's got the D

@Voxera Yeah I get the idea. But it is a complete BS as no browsers are forced to implement and follow it. And any attacker will just ignore your “nice headers”.
It is a complete bullshit invented to appease “Higher ups”. “Look we have a good score” Doesn’t matter is the score doesn’t mean any thing

@NoToJavaScript Which would be why Google is ignoring this. I agree, this seems like paperwork bullshit.

@NoToJavaScript No browser is forced to implement and follow ANYTHING, so that's not a valid argument.

For basics e.g. on CSP, see here:
https://developer.mozilla.org/en-US...

https://en.wikipedia.org/wiki/...

Your argument, does not stand.
The listed headers are protecting browser users against attacks in their browser.
While browsers don't HAVE to implement the headers, they DO.

I know a couple of them:

CSP: Protects against script injections.
Example: You have an XSS injection vulnerability. With a proper CSP, it may be mitigated, as injected scripts cannot work.
Hard to configure, but absolutely worth.

Expect-Ct: Tell the browser to check for certificate transparency, to protect against misbehaving CAs issuing certificates for your domain.
Example: Symantec issued certificates for google.com for "testing purposes".

Feature-Policy: Injection mitigation, again.
Example: XSS again. Some parts of your site requested camera access from the user, but those are safe. Other parts (where the vulnerability is) cannot use it, because the feature policy says otherwise.

Referrer-Policy: This will tell the browser that if the user clicks on a link, the target site (if external) will not be informed on which page he clicked on the link.

Strict-Transport-Security: Tell the browser to not ever try to access your http. This is better than only redirecting, because those redirects could be intercepted.

X-Content-Options: NOSNIFF
Prevents if a user uploads a script file as an image ("script.jpg") to be inserted as a script again. Should not even interfere any normal site.

X-XSS-Protection: 1; mode=block
Tells browsers with a built-in XSS filter, to turn it on and totally block access to your site. Be aware it is only a mitigation, and not even a very powerful one. Only IE and Chrome (and Chrome based) have a filter.

X-Frame-Option: BLOCK or SAMEORIGIN.
Prevents your site being used in iframes. Click jacking attacks can be done if your site is can be embedded.

This is about defense in depth, not about magically making your site secure. Most of them are mitigations, against vulnerabilities of your site, reducing the effects of SOME vulnerabilities for your users.

As securityheaders.com only measures your the use of headers, it creates the grades from their use.
Your site may be perfectly secure without them, but if it isn't (every one writes software with bugs, I don't exclude myself) and the headers reduce the impact. Just see them as that, but not more.

@NoToJavaScript The attacks against those headers protect, are only in effective browsers (and some electron apps, but this is purerly the developers fault then).

Just because you lack the capacity to understand how it work, does not make it shit.

@sbiewald Good comments. Minor addition for Content Security Policy, this is also helpful when using third party elements. While this practice is debatable anyway especially for JS, CSP can at least define valid SHA-256 hashes of the scripts so that no maliciously altered scripts will be loaded if the third party server is hacked.

@M1sf3t The problem is that this will blow up your HTTP headers unless you have the same inline styles on every page, in which case you should just move it to the external CSS file that you have anyway. That will even profit from browser caching.

The nonsense that Google Pagespeed is spouting with inlining critical CSS is actually bad advice.

@Fast-Nop
It's primarily useful when you're procedurally generating your UI on the client. If you're just spitting html from a server, it's of marginal value.

@NoToJavaScript you are mussing the point.

These are not intended to protect the site from the user of the browser.

They are intended to protect a visitor to your site from bad scripts embedded in other pages they might have open in other tabs.

What they do is make sure the browser knows what security measures it can apply to your site without breaking it.

A lot of the ways you traditionally has been able to interact with sites has proven insecure but as many older sites don’t work if all these settings are applied they are opt in by the site.

And some sites might need to expose them self to achieve some goals and just have to make sure the site is safe anyway.

So, if you test your site and find that it works fine with all these settings there are no reason not to use them.

The are not primarily for the sites protection, but for the visitor.
And if the visitor has a bad browser, that is another problem altogether.

@SortOfTested IMO, there's little reason to do it that way because how the UI looks should be consistent, and that can be easily achieved via external CSS. What's created on demand then are basically DOM elements with programmatic classes.

@M1sf3t That can happen with a crap framework where the authors simply have no idea about separation of concerns and create a big ball of mud - probably also replicating HTML's and CSS' functionality with JS.

There's a reason why modern websites are often bloated piles of garbage.

@Fast-Nop
Inline is kind of a rarity anymore. I was just stating the use-cases it applies to. Whereas it is measurably faster, it's a lot of churn and traceability is shit.

Most of the code we write references CSS as symbolic references at design time. The classes are computed, then a top-level stylesheet is programmatically created at runtime based on the user's environment and the existing DOM component hierarchy, accounting for per-client permutations on the data. Binding a symbol representative of the CSS class to a build-time variable allows you to late bind per-client, per-group, per-feature, per-user customization in a simple fashion. Not quite as performant as inline computed styles, but significantly more flexible and a lot less data while still maintaining the data integration needed for that level of customization.