Tips to harden your nginx configuration; part 1

Currently, nginx is the second most popular web server (based on a study of the top 10,000 websites). It is lightweight, fast, robust, supports the major operating systems and is the web server of choice for Netflix, and other high traffic sites. nginx can easily handle 10,000 inactive HTTP connections with as little as 2.5M of memory. In this article, I will provide tips on nginx server security, showing how to secure your nginx installation.

After installing nginx,  you should gain a good understanding of nginx’s configuration settings which are found in nginx.conf. This is the main configuration file for nginx and therefore most of the security checks will be done using this file. By default nginx.conf can be found in [Nginx Installation Directory]/conf on Windows systems, and in the /etc/nginx or the /usr/local/etc/nginx directories on Linux systems.

1. Disable any unwanted nginx modules

Nginx modules are automatically included during installation of nginx and no run-time selection of modules is currently supported, therefore disabling certain modules would require re-compilation of nginx. It is recommended to disable any modules which are not required as this will minimize the risk of any potential attacks by limiting the operations allowed by the web server. To do this, you would need to disable these modules with the configure option during installation. The example below disables the auto index module, which generates automatic directory listings and recompiles nginx.

# ./configure --without-http_autoindex_module
# make
# make install

2. Disable nginx server_tokens

By default the server_tokens directive in nginx displays the nginx version number in all automatically generated error pages. This could lead to unnecessary information disclosure where an unauthorized user would be able to gain knowledge about the version of nginx that is being used. The server_tokens directive should be disabled from the nginx configuration file by setting – server_tokens off.

404 Nginx error

Figure 1 – A 404 Not Found page showing the Nginx version number through the server_tokens directive

3. Control Buffer Overflow Attacks

Buffer overflow attacks are made possible by writing data to a buffer and exceeding that buffers’ boundary and overwriting memory fragments of a process. To prevent this in nginx we can set buffer size limitations for all clients. This can be done through the Nginx configuration file using the following directives:

  • client_body_buffer_size – Use this directive to specify the client request body buffer size. The default value is 8k or 16k but it is recommended to set this as low as 1k as follows: client_body_buffer_size 1k
  • client_header_buffer_size – Use this directive to specify the header buffer size for the client request header. A buffer size of 1k is adequate for the majority of requests.
  • client_max_body_size – Use this directive to specify the maximum accepted body size for a client request. A 1k directive should be sufficient, however this needs to be increased if you are receiving file uploads via the POST method.
  • large_client_header_buffers – Use this directive to specify the maximum number and size of buffers to be used to read large client request headers. A large_client_header_buffers 2 1k directive sets the maximum number of buffers to 2, each with a maximum size of 1k. This directive will accept 2kB data URI.

4. Disable any unwanted HTTP methods

It is suggested to disable any HTTP methods which are not going to be utilized and which are not required to be implemented on the web server. The below condition, which is added under the ‘server’ section in the Nginx configuration file will only allow GET, HEAD, and POST methods and will filter out methods such as DELETE and TRACE by issuing a 444 No Response status code.

if ($request_method !~ ^(GET|HEAD|POST)$ )
	return 444;

Read Part 2 of this article for more tips on nginx configuration hardening
Share this post
    • Hi Tommy,

      It is recommended to disable any HTTP methods that the web server is not making use of in order to prevent potential security exploits through these methods. For example, attackers may abuse the HTTP TRACE functionality to gain access to information in HTTP headers (such as cookies and authentication data) or use the OPTIONS method to expose sensitive information that may help prepare more advanced attacks.

      The example in tip no. 4 shows how to allow GET, HEAD, and POST methods but returns a 444 No response status code when trying to use other methods.

      More information about HTTP Methods can be found from the following link –


  • Hi Glenn, Thanks for explaining the importance of disabling the http on nginx. However, does the configuration creates a conflict on server monitoring software? Thanks

    • Hi Colleen,

      I believe that you are referring to disabling any unwanted HTTP methods. With regards to server monitoring, this would really depend on the monitoring tools that you are currently using. For example, if your tool performs monitoring checks by sending HEAD requests and you have chosen to disable HEAD requests, then this could potentially cause issues.


    • Hi Stuart,

      Thank you for your comment. Yes, this is another method that can be used. However, do note that ‘return’ is considered safe inside an if statement, as explained from the provided link:

      “The only 100% safe things which may be done inside if in a location context are:

      return …;
      rewrite … last;”

      Therefore, both methods are accepted.


  • Leave a Reply

    Your email address will not be published.