Search code examples
securitynginxnginx-configfortify

Is it safe to return 200 status code for 403 forbidden or 405 not allowed response in nginx

I am using react js for my app.

During Fortify web inspect scans, I got some issues which are related to missing http headers. Please note that I have already applied necessary headers.

Now, In detail of these issues they have mentioned that http headers are not present when 403 Forbidden or 405 Not Allowed Nginx responses received.

For ex. Web inspect tries to attack Like www.xyz.com/static/

static folder here is the one which contains js and CSS folders to keep bundle files. (Referring to build folder)

When we try to access this static folder via browser or postman it will return the 403 response from nginx server.

So same thing with this web inspect where it will try to attack by accessing static folder it gets 403 Forbidden which is Nginx response and due to that the headers are not being applied to it. Hence it is returning as an issue.

Same thing for 405 response, web inspect is trying to access like www.xyz.com/ with OPTIONS method and in return it gets 405 Nginx response which does not have the http headers being applied. Hence it is returing as an issue.

In order to resolve this I applied below code in my nginx.config file,

.....
server {

add_header X-Frame-Options "SAMEORIGIN"
add_headed Pragma "no-cache";
......

error_page 403 =200 @custom_403

location @custom_403 {
 return 200 "
  <html>
   <body>
     403 Forbidden
   <body>
  </html>  
 ";
}

error_page 405 =200 @custom_405

location @custom_405 {
 return 200 "
  <html>
   <body>
     405 Not Allowed
   <body>
  </html>  
 ";
}

With above code all the issues have been resolved, but I just wanted to check like is it safe in terms of security?

or is there any other way to set http headers on the responses like 403 and 405 which are default nginx response.

Thanks in advance.

Solution

  • You've posed two related questions:

    Should a 200 HTTP status code be returned in error conditions like the ones you describe, or does it cause a security issue?

    In the situation you describe, it is "incorrect" to return a 200 result. A 200 result says both that the request is valid and that the server is returning valid content. You should always inform the requesting party of their error in entering a URL that is not valid for them. Consider the situation where a search engine hits this URL for some reason. Do you want it consider this URL as valid and return it in search results? Whether this situation is a security issue depends a bit on your definition of security. I would tend towards yes.

    Does nginx have a method for returning headers consistently in non-error and error conditions?

    Yes, you want to use the always flag on the end of the add_header directive to have nginx return headers in error conditions.

    add_header X-Frame-Options "SAMEORIGIN" always;

    reference: https://nginx.org/en/docs/http/ngx_http_headers_module.html