[Blog](/blog)

Show links

Resources

[Blog](/blog)

[Breaches](/breaches)

[eBooks, reports, & more](/resources)

[Events](/events)

[News](/news)

[Attack Surface Management](/category/attack-surface-management)

Show links

Categories

[Attack Surface Management](/category/attack-surface-management)

[Company News](/category/company-news)

[Compliance and Regulations](/category/compliance-and-regulations)

[Cybersecurity](/category/cybersecurity)

[Data Breaches](/category/data-breaches)

[DevOps](/category/devops)

[Human Cyber Risk](/category/human-cyber-risk)

[Risks and Vulnerabilities](/category/risks-and-vulnerabilities)

[Third-Party Risk Management](/category/third-party-risk-management)

[Vendor Risk Management](/category/vendor-risk-management)

[How to Build a Tough NGINX Server in 15 Steps](/blog/how-to-build-a-tough-nginx-server-in-15-steps)

Publish date

October 13, 2026

{x} minute read

# How to Build a Tough NGINX Server in 15 Steps

[Get a demo](/contact-sales)

[Free trial](/demo)

[Download the PDF guide](/resources/complete-guide-to-data-breaches)

[Free trial](/demo)

Written by

[Abi Tyas Tunggal](/team/abi-tyas-tunggal)

Writer and Senior Product Manager at UpGuard.

Abi's work has influenced leaders across cybersecurity, technology, and financial services.

Reviewed by

[Kaushik Sen](/team/kaushik-sen)

Chief Marketing Officer

Kaushik has a background in software engineering, enterprise solution architecture, and data analytics. He brings a unique, data-driven perspective to cybersecurity education.

Table of contents

eBook

A Complete Guide to Data Breaches

Free resource

### A Complete Guide to Data Breaches

Learn how to avoid a costly data breach with a comprehensive prevention strategy.

[Download now](/resources/complete-guide-to-data-breaches)

Arguably--in that people literally argue about it--there are two types of web servers: traditional servers like Apache and IIS, often backhandedly described as “full-featured,” and “lightweight” servers like [Lighttp](https://www.lighttpd.net/) and nginx, stripped down for optimum memory footprint and performance. Lightweight web servers tend to integrate better into the modern, containerized environments designed for scale and automation. Of these, nginx is a frontrunner, serving major websites like Netflix, Hulu and Pinterest. But just because nginx slams Apache in performance doesn’t mean it’s immune from the same security problems the old heavyweight endures. By following our 15 step checklist, you can take advantage of nginx’s speed and extensibility while still serving websites secured against the most common attacks.

## **1. **Containerization

There’s more to containers ([Docker, Vagrant](/blog/docker-vs-vagrant), [Rocket](https://coreos.com/blog/rocket/)) than (re)deployability. They also isolate applications in a discrete Linux namespace, protecting the underlying server (and any other containers) from the nginx process, which is what you want if someone else happens to take it over. However, deployability itself adds a type of security as well. By standardizing configurations for automation, you’re more likely to find, and consequently fix, problems that would have gone unrecognized in manually managed environments. Passing configuration options to a Docker container as environment variables, for example, requires that the configuration be closely examined and streamlined so it can be infinitely redeployed in ephemeral containers, sort of like the ending of The Prestige.

## 2. Remove Unwanted Modules

Despite nginx’s already lean profile, you can shrink its attack surface even further by removing unused modules from the installation. Best practice dictates that only the modules actually used in serving the legitimate content should be enabled, keeping the web server’s functionality to a minimum and thus its ability to be compromised. Obviously this could cause a major problem if you uninstall a module you actually need, so be sure your test and/or QA environments reflect the lack of these modules in production.

## 3. Keep Nginx Up to Date

Simple right? But simple is good. When there’s an easy way to increase resiliency, don’t overlook it. The package management for your distro, apt or yum probably, should offer the latest supported version, but you can check [nginx.org](https://nginx.org/en/download.html) for more information. You may need to access an additional repository such as [epel](https://www.tecmint.com/how-to-enable-epel-repository-for-rhel-centos-6-5/) for RedHat and CentOS if your distro’s repository doesn’t have the version you want.

yum update nginx\
or\
apt-get update nginx

Like any software, if you don’t keep it up to date, known [vulnerabilities](https://www.upguard.com/blog/vulnerability) will stack up on your system until someone finally exploits one.

## 4. Consider SELinux 

Enabling [SELinux](https://selinuxproject.org/page/Main_Page) should always be done with care, as it’s very good at what it does and can kill functionality in a second. But when properly configured, especially when an application specific policy exists, as with nginx, SELinux can truly harden a system against almost anything. The nginx policy and accompanying documentation can be [found here](https://sourceforge.net/projects/selinuxnginx/). Getting to the right SELinux configuration is a process of trial and error, so expect a time investment when going this route and weigh that against the relative increase in security it provides to determine whether it’s right for you.

## 5. Use Sitewide SSL 

Thankfully the mentality on SSL is shifting away from “it should be on pages that need it” to “it should be everywhere and the only choice.” [SSL](/blog/ssl-certificate) is the most basic form of web security, in that it encrypts communication between the server and its clients. Given the low cost and low difficulty of implementing sitewide SSL with a trusted certificate, the question isn’t whether the content being encrypted warrants privacy, but why you would choose to pass any communication in plain text across the internet. Just as important as using SSL is using it correctly; that means using modern [encryption](https://www.upguard.com/blog/encryption) standards such as SHA256 and 2048-bit keys. As stronger encryption becomes available and the current standards get cracked, servers too will have to adapt. Security is a habit, not an on-off switch.

## 6. Disable Weak Cipher Suites

Another part of correct SSL implementation is disabling legacy cipher suites such as RC4 that are still included with web servers for backwards compatibility. There really should be no reason to leave these enabled, especially since the consequences of exploitation are high, so unless you know that a client must use a specific legacy cipher suite, turn them off. A secure cipher suite in ssl.conf would resemble the following, note that the order is important:

ssl\_cipherssl\_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

A simple edit to the config file will block insecure suites and render their vulnerabilities harmless. Consider too explicitly disabling SSLv2 and v3 and using only the more secure TLS mechanisms.

## 7. Secure Diffie-Hellman

[Diffie-Hellman](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) (DH) is a secure key exchange mechanism that can be secured even further by generating a custom DH group with OpenSSL. To do so, run openssl dhparam -out dhparams.pem 4096. This will generate the dhparams.pem file you can place along with your SSL certificates. Once you have it in a good place, edit the ssl.conf file and add the following: ssl\_dhparam /your/path/dhparams.pem;. Unless you’re a cryptography expert, don’t worry too much about the details of this, just know that the default DH group is considered less secure and these few steps tighten it up.

## 8. Enable HTTP Strict Transport Security

This is a fancy way of saying “only allow HTTPS.” By using [HTTP Strict Transport Security](https://www.owasp.org/index.php/HTTP_Strict_Transport_Security), you ensure that all of your pages only load on encrypted connections. All modern browsers support HTTPS so there’s no reason not to set this and make full use of the encrypted channel you’ve already set up. Add the following line to the server section of your ssl config file:

add\_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

Not setting this means someone can potentially still connect to your site on an unencrypted connection and pass information in plain text, for example with a manually created bookmark pointing to http\://.

## 9. Disable the server\_tokens Directive

In nginx, the [server\_tokens directive](https://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens) controls what information is advertised about the server. Be sure to disable this, as there’s no need to inform anonymous people what type and version of software is running. Every web server has an [attack surface](/blog/attack-surface), so advertising the specifics of what’s running quickly narrows the focus for anyone trying to attack it. Add the following line to your nginx.conf file to disable broadcasting this info:

server\_tokens off;

## 10. Deny Automated User-Agents

To prevent scripts, bots and other automated methods of web page retrieval from running against your server, explicitly deny certain user-agents. Applications like [wget](https://en.wikipedia.org/wiki/Wget) can grab entire directory structures at once, making them useful for denial of service attacks or simply accessing any improperly secured files on the website. You want real people using browsers to see your website, not let anyone with specialized tools pick through your web server at will. In the nginx.conf file, add the following:

if ($http\_user\_agent \~\* LWP::Simple|BBBike|wget) {\
return 403;\
}

Factor in the legitimate ways the site is used. If you have some integration or client need for any of these protocols, they will obviously need to remain open. But start with the [least privilege](/blog/principle-of-least-privilege) and open things up as you need them; it’s the golden rule of security.

## 11. Limit Available Methods

Now that you’ve blocked the user-agents you don’t want, you need to regulate the ones you do. Limiting the allowed methods on the server prevents someone from utilizing HTTP calls to manipulate the server in an unforeseen way. By specifying allowed verbs such as GET and POST where applicable, you can rule out the majority of possible methods and restrict clients to a minimal set of commands necessary for normal web browsing. The following is an example of what to add to the nginx.conf file to secure available methods:

add\_header Allow "GET, POST, HEAD" always;\
if ( $request\_method !\~ ^(GET|POST|HEAD)$ ) {\
return 405;\
}

It bears mentioning yet again, but although this does tighten security, it also limits usability. Be sure not to throw the baby out with the bathwater and interrupt regular operations or legitimate traffic with new security measures-- it’s important to know in advance and in detail what your applications require to run properly.

## 12. Control Simultaneous Connections

A web server best practice since the beginning of time, limiting the number of simultaneous connections to the server, both in total and from individual sources, prevents the server from being overwhelmed by connection swarms, whether intentional (DoS) or not. The defaults may not serve you here, and there are [some recommended settings](https://www.nginx.com/blog/tuning-nginx/), but ultimately every environment is unique and optimum settings can only be found by studying the actual activity of the server in production. If you have established baselines of your traffic patterns, you can tweak the connection settings to the data you’ve collected, perhaps placing a ceiling slightly above your maximum expected connections for legitimate traffic.

## 13. Prevent Buffer Overflow 

Like connections, limiting the buffer prevents clients from overwhelming the resources of the server. Here is an example of what to add to your nginx.conf file to secure it:

\##buffer policy\
client\_body\_buffer\_size 1K;\
client\_header\_buffer\_size 1k;\
client\_max\_body\_size 1k;\
large\_client\_header\_buffers 2 1k;\
\##end buffer policy

This too is nothing new to nginx, and should be standard practice with any web server, but goes to the point that despite its innovations, nginx IS a web server and these basic configurations still need to be scoped to your environment to prevent accidental or malicious exploitation.

## 14. XSS Protection

Cross-site scripting (XSS) is a type of web attack that allows someone to execute a script through unsanitized data entry for content then displayed on the site. For example, if someone builds a profile on a social media site not protected against this and injects a background script into their details, they could then gather information on anyone else from the site visiting their page. One way to protect against this in nginx is to force “X-XSS protection” headers to the client. Do so by adding the following to your ssl.conf file: 

add\_header X-XSS-Protection "1; mode=block";

## **15. Configuration Testing**

The only way to make sure all this stuff is setup correctly across all of your servers is to have continuous visibility into your environment that tests these configurations against a policy. This allows you to track your configs and their changes over time. Do you have the same version of nginx in dev, test and production? Do all your ssl.conf files have that one crucial line protecting your customer data? If you can’t answer those kinds of questions without looking on every server, you might want to try [UpGuard](/), that’s what we’re built for, and the first 10 nodes are free.

eBook

A Complete Guide to Data Breaches

Free resource

### A Complete Guide to Data Breaches

Learn how to avoid a costly data breach with a comprehensive prevention strategy.

[Download now](/resources/complete-guide-to-data-breaches)

## Related posts

Learn more about the latest issues in cybersecurity.

Attack Surface Management

#### [Find Out if You're Exposed on the Dark Web](/blog/find-out-if-youre-exposed-on-the-dark-web)

Answer 5 quick questions to predict what a dark web scan will find about your company. Then run the free scan to see your real exposure.

[](/team/lance-turner)

[Lance Turner](#)

October 14, 2026

Data Breaches

#### [Your First Dark Web Scan Report, Explained](/blog/your-first-dark-web-scan-report-explained)

You scanned your domain. What do the results mean?

[](/team/lance-turner)

[Lance Turner](#)

October 13, 2026

Cybersecurity

#### [12 Cybersecurity Horror Stories of 2026 (No Costume Required)](/blog/cybersecurity-horror-stories-2026)

A warning ignored once becomes a headline. Read more about these 12 real 2026 cybersecurity incidents, and the sign each one gave before it made the news.

[](/team/revashni-moodley)

[Revashni Moodley](#)

October 14, 2026

Data Breaches

#### [Good Security Rating? Your Dark Web Exposure Says Otherwise](/blog/good-security-rating-your-dark-web-exposure-says-otherwise)

Scan your domain to see just how exposed you are on the Dark Web.

[](/team/lance-turner)

[Lance Turner](#)

October 13, 2026

Cybersecurity

#### [Left Unsupervised: 10 Times Access Outlived Its Authorization](/blog/10-times-access-outlived-authorization)

Access granted once shouldn’t mean access forever. Read more on how unmonitored access caused 10 of these real-life breaches and what they taught us.

[](/team/revashni-moodley)

[Revashni Moodley](#)

October 29, 2026

Cybersecurity

#### [Surviving a LockBit Ransomware Attack: The ROI of Visibility](/blog/surviving-a-lockbit-ransomware-attack)

Read how veteran CISO Nick Gicinto saved his alma mater from a LockBit ransomware attack by discarding the standard playbook.

[](/team/nicholas-sollitto)

[Nicholas Sollitto](#)

June 1, 2026

[All posts](/blog)

Experience superior visibility and a simpler approach to cyber risk management

[Get a demo](/contact-sales)

[Free trial](/demo)