aidantwoods

3 ms·

1.
SecureHeaders v2.0 for PHP(github.com)
3 points by aidantwoods 9y ago|0 comments
2.
“/* should we even bother? */” nomx: The world's most secure communications(scotthelme.co.uk)
15 points by aidantwoods 9y ago|1 comments
3.
Building a WiFi Enabled USB Rubber Ducky with a Raspberry Pi 0 w(aidanwoods.com)
3 points by aidantwoods 9y ago|0 comments
4.
Disabling JavaScript and cookies on non-secure pages in Chrome(aidanwoods.com)
2 points by aidantwoods 10y ago|0 comments
5.
by aidantwoods 10y ago
Hey. Just to let you know that the project is now installable from Packagist! https://packagist.org/packages/aidantwoods/secureheaders
6.
by aidantwoods 10y ago
Should have both those completed pretty soon :) Someones already raised the issue, and I'm working on it! https://github.com/aidantwoods/SecureHeaders/issues/3
7.
by aidantwoods 10y ago
It can be simplified, but it would reduce its usefulness to include wild cards. By specifying paths more explicitly, I whitelist less of the domain (and consequently reduce the chances that I'll whitelist something this is user control
8.
by aidantwoods 10y ago
CSP headers are more often than not: static (bar nonces). Having them be dynamic is really just a bonus to the management aspect you gain here. (You can make sure every page truly only has access to load the sources it needs though). As far
9.
by aidantwoods 10y ago
Generally with these things, avoiding user input is one of the best ways at making sure they can't inject things into the header value. I'd recommend manually writing the list of sources for the page type. There isn't really
10.
by aidantwoods 10y ago
IMHO, I don't think a broad statement about where headers should be handled can really be made. For the one liners, sure. You can set up HSTS once and forget about it. For something like CSP, it becomes very difficult to maintain a lis
11.
Secure Headers for PHP(aidanwoods.com)
57 points by aidantwoods 10y ago|18 comments