some minor rewrites to allowmore aggressive CSP settings on the site

[ChaseWPDEV]

Got sucked down the Content-Security-Policy headers rabbit hole on another project recently. Looks like we can implement this on the site with some minor changes. Namely:

• Lite rewrite on the pdf parser.
• Switching to json for the sample data (seems there's a known issue in d3 core https://github.com/d3/d3/issues/1904 that's on the "someday" track for implementation)

[ChaseWPDEV]

Note: if you use the .htaccess on local apache, and it implements it, you won't be able to load the site with webpack --mode=development as the source maps use eval all over the place. We'll either want to :

1. comment that out on local and ensure it doesn't get pushed up
2. Add .htaccess to the .gitignore and manage that separately.

[twgardner2]

wish I understood this better, but it runs and I trust you, so ¯_(ツ)_/¯

[ChaseWPDEV]

@twgardner2 High level: -XSS is a mechanism by which hackers use spells and potions to run stuff on our server and inject sneaky shtuff onto a website to harm its users by running malicious code in their browsers. -We already had an extremely small (arguably no) attack surface, as we have no server-side templating. -Implementing strong CSP is a "defense in depth" measure -- even if someone manages to inject some sneaky stuff onto the server, we're adding a security directive to the headers that says "hey browser, we don't do any sneaky stuff on our website, so if you see something that tries to send the users data somewhere, don't run it."

Arguably, not a necessary step, but since we can, we should. It also allows us to score aces on site scans such as this one: https://snyk.io/website-scanner/