26

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?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Uğurcan Şengit
  • 976
  • 1
  • 11
  • 31

3 Answers3

15

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!

nickspoon
  • 1,347
  • 12
  • 18
  • 1
    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. – Taytay Aug 06 '19 at 13:49
  • https://stackoverflow.com/questions/59610943/x-frame-options-deny-is-not-wokring-for-spring-boot-rest-api?noredirect=1#comment105385341_59610943 ,@nickspoon, this is a similar problem only. Can you please share your thoughts – Priya Jan 06 '20 at 11:30
15

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.

Steve Chadbourne
  • 6,873
  • 3
  • 54
  • 82
  • 1
    The linked article section says "Additionally the client should send an X-Frame-Options: deny". The _client_. Not the _server_. – nickspoon Dec 12 '17 at 02:42
  • 4
    @nickspoon I think there's a typo in the OWASP article since `X-Frame-Options` [is a response header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options). – Chopin Jul 27 '18 at 00:30
  • You're right. After your comment I tried contacting OWASP in various ways (before they moved to github) but never received any response. @Taytay has now successfully had the article updated so I've updated my answer – nickspoon Aug 07 '19 at 00:41
  • https://stackoverflow.com/questions/59610943/x-frame-options-deny-is-not-wokring-for-spring-boot-rest-api?noredirect=1#comment105385341_59610943 , @Stev. this is a similar problem. Can you please add your thoughts – Priya Jan 06 '20 at 11:31
  • 2
    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. – Ed Graham Aug 04 '21 at 09:31
0

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.

Ryan Armstrong
  • 1
  • 1