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 controllable in the domain). I'll usually try to allow down to specific files in CSP if I can.
Hosting font awesome myself costs me money, pointing to cloudflare is free
Edit: check out my site vs. a few others using Google's CSP evaluator – you'll probably find a lot with known CSP bypasses due to their whitelisting.
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 as using the class to do it goes, there are other benefits other than just CSP management: auto cookie upgrades and error messages about poor configuration to name a few.
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 a safe way to just scan the page for (safe) resources unfortunately (how could you tell which resources were meant to be there?)
Point of the (CSP) part of this class is to let you break down your CSP into distinct components and then combine them together.
E.g. You need to embed a tweet – that twitter embed code will require you to add script, style, and image sources to your CSP. You could file them all quite nicely in the CSP array format, and call that variable `$twitterCSP`.
If twitter changes things in the future RE the required sources, you now know what to amend. If you decide you no longer want tweets on your page, you can get rid of unnecessary sources by deleting just `$twitterCSP` from your code – instead of leaving in sources you don't need, or having to trudge through the entire CSP string trying to figure out which sources you added to make twitter work.
Goal is source management, not auto generating the list.
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 list of sources very quickly. Also, for parts of CSP like nonces too – from a usability perspective, it's a lot easier to pass a nonce around in the application layer, as opposed to generating it at the Apache/Nginx level, and then trying to insert it into the HTML as the page goes out.
Goal here is to make things like CSP easier to use. Integrating security headers into a language devs are already familiar with achieves that.
https://packagist.org/packages/aidantwoods/secureheaders