revisit "Countermeasures" section

[TallTed]

security-considerations/index.bs

Lines 112 to 115 in d2dc6d6

	### Countermeasures ### {#serving-user-created-files-countermeasures}
	* Multiple agents can create files on the same server, which could render `same-origin` security boundaries useless.
	* As one possible countermeasure, servers could add a [`Content-Security-Policy: sandbox`](https://www.w3.org/TR/CSP3/#directive-sandbox) header to artificially enable `same-origin` security policies for files served on the same origin.

The first bullet under countermeasures is more of a vulnerability than a countermeasure, and should be moved.... or rephrased to focus on how "same-origin security boundaries" can work as a countermeasure.

(The current point of the first bullet should be moved to the vulnerabilities section, or start a new section focusing on this vulnerability, if the document restructuring discussed previously is implemented.)

Having only one or two countermeasures seems insufficient for an entire section, meant to address all vulnerabilities. But having few countermeasures is fine if they are addressing a single vulnerability, as in the previously suggested restructuring.

[josephguillaume]

Just adding link to existing discussion:
Prevent or sanitise HTML on write by default for unauthenticated users
CommunitySolidServer/CommunitySolidServer#1596

Limiting writing of executable code should be included as a partial countermeasure, at least:

• Prevent or sanitise HTML on write by default for unauthenticated users
• Use data validation constraints - if a container should only contain RDF, don't allow writing executable code in any form, including HTML, js, markdown with unsanitised HTML..., SVG ...