Is it Meaningful to Add 'x-frame-options' in an Restful API

Question

We are developing a restful API that fulfils some various events. We have done a Nessus vulnerability scan to see security leaks. It turned out that we have some leaks leads to clickjacking and we have found the solution. I have added x-frame-options as SAMEORIGINin order to handle problems.

My question here is that, since I am an API, do I need to handle clickjacking? I guess 3rd party user should be able to reach my API over an iframe and I don't need to handle this.

Do I miss something? Could you please share your ideas?

Twitter

Answer 1

Edit 2019-10-07: @Taytay's PR has been merged, so the OWASP recommendation now says that the server should send an X-Frame-Options header.

---

Original answer:

OWASP recommends that clients send an X-Frame-Options header, but makes no mention of the API itself.

I see no scenario where it makes any sense for the API to return clickjacking security headers - there is nothing to be clicked in an iframe!

Suchlike

I believe this is a typo because X-Frame-Options is a response header, not a client header. I've submitted a pull request to the OWASP cheatsheet repo to fix the recommendation. – Koeninger

#59611443 ,@nickspoon, this is a similar problem only. Can you please share your thoughts – Fourierism

Answer 2

OWASP recommends that not only do you send an X-Frame-Options header but that it is set to DENY.

These are recommendations not for a web site but for a REST service.

The scenario where it makes sense to do this is exactly the one the OP mentioned - running a vulnerability scan.

If you do not return a correct X-Frame-Options header the scan will fail. This matters when proving to customers that your endpoint is safe.

It is much easier to provide your customer a passing report than have to argue why a missing header does not matter.

Adding a X-Frame-Options header should not affect the endpoint consumer as it is not a browser with an iframe.

Bertero

The linked article section says "Additionally the client should send an X-Frame-Options: deny". The client. Not the server. – Suchlike

@Suchlike I think there's a typo in the OWASP article since X-Frame-Options is a response header. – Pritchett

You're right. After your comment I tried contacting OWASP in various ways (before they moved to github) but never received any response. @Koeninger has now successfully had the article updated so I've updated my answer – Suchlike

#59611443 , @Stev. this is a similar problem. Can you please add your thoughts – Fourierism

Whilst undeniably sensible advice, this doesn't answer the OP's question about whether it is meaningful to provide this header in an API response. It has no more meaning than an X-Powered-By header; the client will not take the slightest notice of it. – Perchloride

Answer 3

In addition to the OWASP recommendation and reasons stated in the other answers, there are legitimate attacks that can be conducted against frameable API responses containing sensitive information. See: GOTCHA: Taking phishing to a whole new level.

Essentially, the attack manipulates the sensitive information to deceive target users to disclose the information to the attacker. Therefore, whether X-Frame-Options or Content-Security-Policy (with the frame-ancestors directive), API responses should be restricted from being framed by arbitrary origins.

Fermi