11–20 of 36 posts
Earlier quoted context omitted.
Because it doesn't eliminate the Server header, "off" will return "Server: nginx". Just one of several "fuck you" features in nginx.
Server: header makes people gone mad?
HN uses x-frame-options:"DENY" to good effect which takes care of a fair number of click-jack tricks, it also uses strict-transport-security. But there is only so much you can do with headers, the real risks are in the documents themselves. How about a pair in the primary document disabling any kind of javascript execution in the space between the tags. And those tags should only work in the primary document.
But wouldn't folks still be able to inject scripts by just writing `alert('hi')`?
It's unfortunate that response headers on a secure website need to be bloated so much to receive benefits that should be default on modern sites. I imagine a world where you specifically have to opt-in to unsafe behavior, not the other way around, but of course this would break many existing sites. For those of you looking at this, I've found the X-Frame-Options (to prevent clickjacking via iframe) and Content-Securi…
I wish some way existed to prevent clickjacking (e.g. via invisible iframe) without actually banning frames. There are useful applications for framing another site that can't be achieved by any other means, apart from writing a browser extension. And framing a site without making it invisible seems like unfortunate collateral damage.
HN uses x-frame-options:"DENY" to good effect which takes care of a fair number of click-jack tricks, it also uses strict-transport-security. But there is only so much you can do with headers, the real risks are in the documents themselves. How about a pair in the primary document disabling any kind of javascript execution in the space between the tags. And those tags should only work in the primary document.
For people using Node/Express, Helmet is a useful little library that lets you add these security headers and CSP pretty easily: https://github.com/helmetjs/helmet
I've found HPKP and HSTS easy to trivial, but gave up on deploying CSP. It's major refactoring when so much stuff directly includes 3rd party CSS and script, or just injects static CSS and JS in to pages inline.
> It's major refactoring when so much stuff directly includes 3rd party CSS and script, or just injects static CSS and JS in to pages inline. You can still use CSP, and whitelist specific third-party domains. (There's no way to whitelist inline code, though, and if there were it'd be more work than eliminating it and moving it to files.) But the refactoring is well worth doing. By eliminating inline JavaScript and of…
That's not completely true - the nonce attribute (specify a nonce in the CSP header, have nonce=that on every script tag) or by sending the hashes of the inline scripts upfront in the CSP header.
It doesn't give you inline code in attributes (e.g. onclick) but it's a big help for migrating.
It's unfortunate that response headers on a secure website need to be bloated so much to receive benefits that should be default on modern sites. I imagine a world where you specifically have to opt-in to unsafe behavior, not the other way around, but of course this would break many existing sites. For those of you looking at this, I've found the X-Frame-Options (to prevent clickjacking via iframe) and Content-Securi…
> I've found the X-Frame-Options (to prevent clickjacking via iframe) I wish some way existed to prevent clickjacking (e.g. via invisible iframe) without actually banning frames. There are useful applications for framing another site that can't be achieved by any other means, apart from writing a browser extension. And framing a site without making it invisible seems like unfortunate collateral damage.
Earlier quoted context omitted.
> It's major refactoring when so much stuff directly includes 3rd party CSS and script, or just injects static CSS and JS in to pages inline. You can still use CSP, and whitelist specific third-party domains. (There's no way to whitelist inline code, though, and if there were it'd be more work than eliminating it and moving it to files.) But the refactoring is well worth doing. By eliminating inline JavaScript and of…
> There's no way to whitelist inline code That's not completely true - the nonce attribute (specify a nonce in the CSP header, have nonce=that on every script tag) or by sending the hashes of the inline scripts upfront in the CSP header. It doesn't give you inline code in attributes (e.g. onclick) but it's a big help for migrating.