Thoughts on a 'csp.txt' Wellknown suffix

Hi All,

First post here so go easy on me :)
I proposed a 'csp.txt' Wellknown suffix to ietf.org and was hoping to get
this group's thoughts/concerns.

The concept is simply that a plaintext 'csp.txt' file would describe the
Content-Security-Policy (CSP)
directives/values required for other origins to embed its content. This can
optionally articulate those values
on a per-path or per-subdomain basis.

Some examples:
#1

   1. Content-Security-Policy: font-src example.com; connect-src example.com

#2

   1. Path: /fonts
   2. Content-Security-Policy: font-src example.com;
   3. Path: /scripts
   4. Content-Security-Policy: script-src example.com; connect-src
   example.com
   5. Path: iframe.example.com
   6. Content-Security-Policy: frame-src example


While i do appreciate that some people might instinctively think that this
isn't necessary, I would argue this will provide
a few key benefits.

1/ We all know that appsec engineers are struggling to implement the
minimum (most secure) CSP changes required to embed
content.
This happens because investigating exactly what to whitelist can be time
consuming and technically challenging, and
because content providers do not often articulate what needs to change in a
CSP to support them. My hope is that if we
start expecting csp.txt files from content providers then we will get them,
relieve ourselves of replicating the same CSP
investigations that a hundred others, and be more secure.

2/ It may help towards a more standardised approach for hosting content.
For example, I've seen that several content sites might host scripts on
s.example.com or have a tracking pixel on t.example.com.
This is great for CSP, as you can lock down the exact directives you need
for the subdomains which need them; and you can ignore
any you don't need. I see a lot of sites which seem to have no rhyme or
reason to how they lay out their content, and it's infuriating.
Particularly when they host their content on the same domain as their
website, which has its own locally hosted Angular
(CSP bypass anyone?).

3/ Often, half the domains in large CSPs look like gibberish as they are
dynamically loaded JS files. It's difficult, at a glance,
to attribute these domains to their parents (where we actually wanted to
get content from); which makes it tricky for appsec engineers
to understand the risks associated with each content provider.

4/ Many providers like to arbitrarily change the domains for
dynamically loaded content, assuming that everything will work because
their users/customers have the root script URI. When this happens, we don't
know if they have been hacked or just too lazy to explain
that they have changed some URLs. Now we can check a simple file.

Possibly a few tenuous arguments there, but generally I think it's an ok
idea. Yes? No?

- Daniel Reece