megamansec/gixy-next repository overview

⁠Gixy-Next: NGINX Configuration Security Scanner for Security Audits

⁠Overview

Gixy-Next (Gixy) is an open-source NGINX configuration security scanner and hardening tool that statically analyzes your nginx.conf to detect security misconfigurations, hardening gaps, and common performance pitfalls before they reach production. It is an actively maintained fork of Yandex's Gixy⁠. Gixy-Next's source code is available on GitHub⁠.

Gixy-Next can also be run in the browser on this page⁠. No download is needed; you can scan your configurations on the website (locally, using WebAssembly).

⁠Quick start

Gixy-Next (the gixy or gixy-next CLI) is distributed on PyPI⁠. You can install it with pip or uv:

# pip
pip3 install gixy-next
# uv
uv pip install gixy-next

You can then run it:

# gixy defaults to reading /etc/nginx/nginx.conf
gixy
# But you can also specify a path to the configuration
gixy /opt/nginx.conf

You can also export your NGINX configuration to a single dump file (see nginx -T Live Configuration Dump⁠):

# Dumps the full NGINX configuration into a single file (including all includes)
nginx -T > ./nginx-dump.conf
# Scan the dump elsewhere (or via stdin):
gixy ./nginx-dump.conf
# or
cat ./nginx-dump.conf | gixy -

⁠Web-based scanner

Instead of downloading and running Gixy-Next locally, you can use this webpage⁠ and scan a configuration from your web browser (locally, using WebAssembly).

⁠Scan with Docker

Gixy-Next is available as a Docker image from Docker Hub⁠ or GitHub Registry⁠.

Scan a local config file by mounting it into the container:

# Use Github Registry
docker run --rm -v "$PWD/nginx.conf:/nginx.conf:ro" ghcr.io/megamansec/gixy-next /nginx.conf
# Or Docker Hub
docker run --rm -v "$PWD/nginx.conf:/nginx.conf:ro" megamansec/gixy-next /nginx.conf

Scan an NGINX live configuration dump:

# Dumps the full NGINX configuration into a single file (including all includes)
nginx -T > ./nginx-dump.conf
# Use Github Registry
docker run --rm -v "$PWD/nginx-dump.conf:/nginx-dump.conf:ro" ghcr.io/megamansec/gixy-next /nginx-dump.conf
# Or Docker Hub
docker run --rm -v "$PWD/nginx-dump.conf:/nginx-dump.conf:ro" megamansec/gixy-next /nginx-dump.conf

Scan from stdin:

# Use Github Registry
nginx -T | docker run --rm -i ghcr.io/megamansec/gixy-next gixy-next -
# Or Docker Hub
nginx -T | docker run --rm -i megamansec/gixy-next gixy-next -

⁠What it can do

Gixy-Next can detect a wide range of NGINX security and performance misconfigurations across nginx.conf and included configuration files. The following plugins are supported:

• [add_header_content_type] Setting Content-Type via add_header⁠
• [add_header_multiline] Multiline response headers⁠
• [add_header_redefinition] Redefining of response headers by "add_header" directive⁠
• [alias_traversal] Path traversal via misconfigured alias⁠
• [allow_without_deny] Allow specified without deny⁠
• [default_server_flag] Missing default_server flag⁠
• [error_log_off] error_log set to off⁠
• [hash_without_default] Missing default in hash blocks⁠
• [host_spoofing] Request's Host header forgery⁠
• [http_splitting] HTTP Response Splitting⁠
• [if_is_evil] If is evil when used in location context⁠
• [invalid_regex] Invalid regex capture groups⁠
• [low_keepalive_requests] Low keepalive_requests⁠
• [merge_slashes_on] Enabling merge_slashes⁠
• [missing_worker_processes] Missing worker_processes⁠
• [origins] Problems with referer/origin header validation⁠
• [proxy_buffering_off] Disabling proxy_buffering⁠
• [proxy_pass_normalized] proxy_pass path normalization issues⁠
• [regex_redos] Regular expression denial of service (ReDoS)⁠
• [resolver_external] Using external DNS nameservers⁠
• [return_bypasses_allow_deny] Return directive bypasses allow/deny restrictions⁠
• [ssrf] Server Side Request Forgery⁠
• [stale_dns_cache] Outdated/stale cached DNS records used in proxy_pass⁠
• [status_page_exposed] Ensures that status_page is not exposed to the world⁠
• [try_files_is_evil_too] try_files directive is evil without open_file_cache⁠
• [unanchored_regex] Unanchored regular expressions⁠
• [valid_referers] none in valid_referers⁠
• [version_disclosure] Using insecure values for server_tokens⁠
• [worker_rlimit_nofile_vs_connections] worker_rlimit_nofile must be at least twice worker_connections⁠

Something not detected? Please open an issue⁠ on GitHub with what's missing!

⁠Usage (flags)

gixy defaults to reading a system's NGINX configuration from /etc/nginx/nginx.conf. You can also specify the location by passing it to gixy:

# Analyze the configuration in /opt/nginx.conf
gixy /opt/nginx.conf

You can run a focused subset of checks with --tests:

# Only run these checks
gixy --tests http_splitting,ssrf,version_disclosure

Or skip a few noisy checks with --skips:

# Run everything except these checks
gixy --skips low_keepalive_requests,worker_rlimit_nofile_vs_connections

To only report issues of a certain severity or higher, use the compounding -l flag:

# -l for LOW severity issues and high, -ll for MEDIUM and higher, and -lll for only HIGH severity issues
gixy -ll

By default, the output of gixy is ANSI-colored; best viewed in a compatible terminal. You can use the --format (-f) flag with the text value to get an uncolored output:

$ gixy -f text

==================== Results ===================

Problem: [http_splitting] Possible HTTP-Splitting vulnerability.
Description: Using variables that can contain "\n" may lead to http injection.
Additional info: https://gixy.io/plugins/http_splitting/
Reason: At least variable "$action" can contain "\n"
Pseudo config:
include /etc/nginx/sites/default.conf;

	server {

		location ~ /v1/((?<action>[^.]*)\.json)?$ {
			add_header X-Action $action;
		}
	}


==================== Summary ===================
Total issues:
    Unspecified: 0
    Low: 0
    Medium: 0
    High: 1

You can also use -f json to get a reproducible, machine-readable JSON output:

$ gixy -f json
[{"config":"\nserver {\n\n\tlocation ~ /v1/((?<action>[^.]*)\\.json)?$ {\n\t\tadd_header X-Action $action;\n\t}\n}","description":"Using variables that can contain \"\\n\" or \"\\r\" may lead to http injection.","file":"/etc/nginx/nginx.conf","line":4,"path":"/etc/nginx/nginx.conf","plugin":"http_splitting","reason":"At least variable \"$action\" can contain \"\\n\"","reference":"https://gixy.io/plugins/http_splitting/","severity":"HIGH","summary":"Possible HTTP-Splitting vulnerability."}]

More flags for usage can be found by passing --help to gixy. You can also find more information in the Usage Guide⁠.

⁠Configuration and plugin options

Some plugins expose options which you can set via CLI flags or a configuration file. You can read more about those in the Configuration guide⁠.

⁠Gixy-Next for NGINX security and compliance

Unlike running nginx -t which only checks syntax, Gixy-Next actually analyzes your configuration and detects unhardened instances and vulnerabilities.

With Gixy-Next, you can perform an automated NGINX configuration security review that can run locally on every change, whether for auditing, compliance, or general testing, helping produce actionable findings that help prevent unstable/slow NGINX servers, and reduce risk from unsafe directives and insecure defaults.

⁠Contributing

Contributions to Gixy-Next are always welcome! You can help us in different ways, such as:

• Reporting bugs.
• Suggesting new plugins for detection.
• Improving documentation.
• Fixing, refactoring, improving, and writing new code.

Before submitting any changes in pull requests, please read the contribution guideline document, Contributing to Gixy-Next⁠.

The official homepage of Gixy-Next is https://gixy.io/⁠. Any changes to documentation in Gixy-Next will automatically be reflected on that website.

The source code can be found at https://github.com/MegaManSec/Gixy-Next⁠.

⁠What is Gixy? (Background)

Gixy is an NGINX configuration analyzer that was originally⁠ developed by Yandex's Andrew Krasichkov. It was first released in 2017 and has since become unmaintained. It does not support modern versions of Python, contains numerous bugs, and is limited in its functionality and ability to detect vulnerable NGINX configurations. Running the original Gixy today on a modern system will result in the following error:

  File "gixy/core/sre_parse/sre_parse.py", line 61, in <module>
    "t": SRE_FLAG_TEMPLATE,
         ^^^^^^^^^^^^^^^^^
NameError: name 'SRE_FLAG_TEMPLATE' is not defined. Did you mean: 'SRE_FLAG_VERBOSE'?

Gixy-Next, therefore, is a fork that adds support for modern systems, adds new checks, performance improvements, hardening suggestions, and support for modern Python and NGINX versions.