Feature-Policy header

[Lednerb]

Implement Tests for the Feature-Policy: Header.

A web platform API which gives a website the ability to allow and deny the use of browser features in its own frame, and in iframes that it embeds.

Browser Support:
https://caniuse.com/#feat=feature-policy

Further information:
https://developers.google.com/web/updates/2018/06/feature-policy
https://docs.google.com/document/d/1k0Ua-ZWlM_PsFCFdLMa8kaVTo32PeNZ4G7FFHqpFx4E/edit#
https://github.com/WICG/feature-policy/blob/master/features.md

---

Suggestion:

Although the Feature-Policy Header is not standardized and implemented in all web browsers, we can implement a test for this new header.

1. We can test if this header is set.
   1.1 If it's not set, the test will get a score of 50, because the default browser values are used.
2. Site admins should only allow features that are used / useful to reduce a possible attack surface.
   2.1 If wildcards (*) are used, we should set a score of 0, because that's a bad practice.
   2.2 Otherwise the header gets a good score.

If possible features are not used anyway, they can get disabled to reduce the potential attack surface.

[Skeeve]

As this header is not a standard yet, maybe we should use a score type which does not influence the result (info?) as long as it isn't set. We can give the score any value then to inform the customer about this header and it's benefit.

Only if it is set, the score type can be a normal one and we rate it.

[mniemietz]

We already talked about it at our Oberseminar. From our perspective, we should test whether this HTTP header is set. We should not downgrade the rating in case that it is not set.

[Lednerb]

So we can set the scoreType similar to the Public-Key-Pin Rating as bonus.

The header will not influence the Header Score at all and is just a normal rated scan to inform the users about this.