3 ms·

If you generate them on-demand based on the resources included in the page how can you ensure that XSS attacks on the page aren't going to result in hostile sou

If you generate them on-demand based on the resources included in the page how can you ensure that XSS attacks on the page aren't going to result in hostile sources being included in the CSP headers? I'm curious as to what the rules would look like that define a fluid list of sources that can be expanded based on page content but not vulnerable to inline XSS attacks.

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 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.