Security considerations should be consistently organised by security risk?

[philsmart]

FedCM/spec/index.bs

Line 2501 in 8201e01

This section provides a few of the security considerations for the FedCM API. Note that there is a

@npm1 In the context of the Security Horizontal Review #652, should the Security Considerations section of the spec be consistently organised by the security risk/threat as opposed to the mitigation (one of them seems to be already)?

For instance, the Content Security Policy section could be titled 'Injection Attacks'. It could then introduce both the malicious Identity Provider (IdP) and endpoint XSS threats, followed by discussing CSP and the Sec-Fetch-Dest as mitigations for each.

This would make it similar to that discussed by other credential APIs, such as its parent's (I think parent) Security Considerations section.

[philsmart]

Also, it is probably missing something on 'Credential Leakage' (similar to the credential management spec, which might be a sensible starter). XSS that steals the 'token': possibly usable by an attacker if a bearer token of some kind.

[TallTed]

I would expect the primary organization (list) to be either by actions (each of which would have one or more identified vulnerabilities) or by vulnerabilities (each of which would have a list of actions where that vulnerability arises).

If primary organization is by actions, I would expect a second list of vulnerabilities, each with one or more (possible) mitigations.

Mitigations might then be a third list, each possibly with implementation details/suggestions.

[simoneonofri]

hi all,

thank @philsmart to point me on this.

I agree with @philsmart and @TallTed, a well-structured section is something described here:

w3c/vibration#49

The reasoning under this structure is here:

w3c/security-request#71 (comment)

[philsmart]

This has been addressed in #692. Closing this issue.