Add hashes and nonces as friendly directive

[IlCallo]

I know that the package is meant to not use them directly, but sometimes it could be useful to be able to insert nonces and hashes directly instead of relying on the given API methods.
It's actually already doable via csp() method, but with a somehow hacky notation:

'\'sha256-K28TraF0hDSDYoxDYfyCCb5cCVAhDUyT0P1E3a+hKyQ=\''
"'sha256-K28TraF0hDSDYoxDYfyCCb5cCVAhDUyT0P1E3a+hKyQ='"
'\'nonce-xxxxxxxx\''
"'nonce-xxxxxxxx'"

I've not tested those on your library directly but I use them in laravel-securityheaders and they work.

My request, if possible, is to add two more "friendly directive":

• one for nonces, which checks if the string start with a "nonce-" and automatically adds the single quotation marks, while preserving the actual nonce value
• and one for hashes, which checks if the string starts with a "sha[acceptableVersionOfSHA]-" and automatically adds the single quotation marks, while preserving the actual encoded hash value.

[aidantwoods]

This seems like a reasonable thing to do, I'll put this in the next feature release. I'm about to start re-writing some of the internals, including CSP related stuff (part of which will be aiming to classify the various components a bit more specifically internally). So identifying hash and nonce strings will come in as part of that anyway, so should be easy enough to add.

For now, 'nonce-xxx', 'sha256-abc', etc... (with the single quotes) will of course work as you've mentioned with SecureHeaders::csp and SecureHeaders::cspro.
I could probably additionally throw a warning out in the case that the hash is of invalid form, not sure how useful that would be though (since CSP would let you know pretty quickly by not running the hashed content).

---

As a quick sample-size-of-one question, if I made an API endpoint available that generated the nonce (but didn't do anything with it except return it) would that be useful? This would let me update the implementation details via the library as standards change (even if you are loading the nonce in manually).

In general I'd rather guide users to using the included methods for nonces in particular to try to avoid things like static values/reuse, or perhaps something like mt_rand being accidentally used, or having some absurdly low number of bytes. I'm not going to go as far as stopping users from specifying them manually if they want to though.

[IlCallo]

Yeah, a method that just create and returns the nonce could be useful but as a separated class, called by your method which adds it to the CSP rules. In less words: I think that CSP nouce addition and nouce generation should be as decoupled as possible.
I agree with you that it's better to guide users to use the provided methods, my request is just for particular cases. For example, I have some scripts which are downloaded dinamically and placed inline, with CSP3 it's all fine, with CSP2 it's not, because they'll be blocked if I don't put an hash. So I must generate hashes right after build execution, save them in a text file and load them in the configuration file when needed. And of course in this scenario I cannot use the methods of your API, I'm forced to generate them in advance (generating the same 8 hashes for every request doesn't seem a good idea to me).