X-Frame-Options + browsers

[drwetter]

• Remove X-Frame-Options
• Clarify use of headers

Please make sure that for your contribution:

• In case of a new Cheat Sheet, you have used the Cheat Sheet template.
• All the markdown files do not raise any validation policy violation, see the policy.
• All the markdown files follow these format rules.
• All your assets are stored in the assets folder.
• All the images used are in the PNG format.
• Any references to websites have been formatted as [TEXT](URL)
• You verified/tested the effectiveness of your contribution (e.g., the defensive code proposed is really an effective remediation? Please verify it works!).
• The CI build of your PR pass, see the build status here.

[szh]

Discussing in Slack. Main question is what the source is that the x-frame-options header is deprecated.

[jmanico]

According to CanIUse X-Frame-Options support has been consistent (not complete, but consistent) for years.

https://caniuse.com/?search=x-frame-options

[psiinon]

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Frame-Options gives no indications that its depreciated.
The ALLOW-FROM origin is obsolete, but not the whole header.

[drwetter]

First of all, this is a REST API where the client is likely not a browser. I'd suggest to phrase that better in the cheat sheet. curl / java / php client etc do not care about those headers -- IMHO.

@jmanico : Caniuse says The X-Frame-Options header has been obsoleted by the frame-ancestors directive from Content Security Policy Level 2. It's way more flexible, maybe deprecated was the wrong term. Given that and the fact we're talking about a REST API I believe it doesn't hurt to remove that line here.

[jmanico]

First of all, this is a REST API where the client is likely not a browser. I'd suggest to phrase that better in the cheat sheet. curl / java / php client etc do not care about those headers -- IMHO.

Good suggestion, clarifying that this is for web browsers is a good idea.

@jmanico : Caniuse says The X-Frame-Options header has been obsoleted by the frame-ancestors directive from Content Security Policy Level 2. It's way more flexible, maybe deprecated was the wrong term. Given that and the fact we're talking about a REST API I believe it doesn't hurt to remove that line here.

REST API's are frequently used for web clients. But this header is very legacy and we need to clarify the details as the OP suggests.

I do not want to delete this but I do suggest we change with these two considerations:

1. Change X-Frame-Options to X-Frame-Options AND/OR CSP frame-ancestors
2. Explain this is only needed if this API serves web clients and that is not necessary if it does not

Would these suggestions help satisfy your concerns, @drwetter ?