Is it worth adding "x-frame-options" to the Restful API

We are developing a robust API that executes some various events. We checked the Nessus vulnerability to see security leaks. It turned out that we have some leaks that lead to clicks, and we found a solution. I added x-frame-options as SAMEORIGIN to solve the problems.

My question here is that since I am an API, do I need to handle clickjacking? I assume that a third-party user should have access to my API through an iframe, and I do not need to handle it.

Did I miss something? Could you share your ideas?

+14
rest api x-frame-options clickjacking
source share
2 answers

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


Original answer :

OWASP encourages clients to send the X-Frame-Options header, but does not mention the API itself.

I do not see a scenario in which the API makes any sense to return security headers using clickjacking - there is nothing to click in an iframe!

+8
source share

OWASP recommends that you not only send the X-Frame-Options header, but also set it to DENY.

These recommendations are not for the website, but for the REST service.

The scenario in which it makes sense to do this is exactly the one that the OP mentioned - launching a vulnerability scan.

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

It is much easier to provide your client with a missing report than to argue why the missing header does not matter.

Adding an X-Frame-Options header should not affect the endpoint user, as he is not an iframe browser.

+4
source share

All Articles