NGINX must implement replay-resistant authentication mechanisms for network access.

Severity	Group ID	Group Title	Version	Rule ID	Date	STIG Version
medium	V-278390	SRG-APP-000157	NGNX-APP-000590	SV-278390r1172747_rule	2026-01-07	1

Description
A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. Anti-replay is a cryptographically based mechanism; thus, it must use FIPS-approved algorithms. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Note that the anti-replay service is implicit when data contains monotonically increasing sequence numbers and data integrity is ensured. Using DOD PKI is inherently compliant with this requirement for user and device access. Using Transport Layer Security (TLS), including application protocols such as HTTPS and DNSSEC, is also compliant. Configure the information system to use the hash message authentication code (HMAC) algorithm for authentication services to Kerberos, SSH, web management tool, and any other access method.

Description

A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. Anti-replay is a cryptographically based mechanism; thus, it must use FIPS-approved algorithms. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Note that the anti-replay service is implicit when data contains monotonically increasing sequence numbers and data integrity is ensured. Using DOD PKI is inherently compliant with this requirement for user and device access. Using Transport Layer Security (TLS), including application protocols such as HTTPS and DNSSEC, is also compliant. Configure the information system to use the hash message authentication code (HMAC) algorithm for authentication services to Kerberos, SSH, web management tool, and any other access method.

ℹ️ Check
Determine the path to NGINX config file(s): nginx -qT \| grep "# configuration" # configuration file /etc/nginx/nginx.conf: Note: The default NGINX configuration is "/etc/nginx/nginx.conf", though various files may also be included. Identify authentication mechanism in use by checking whether NGINX is configured to protect access to administrative interfaces or APIs: grep -Ri 'auth_' /etc/nginx/nginx.conf grep -Ri 'proxy_pass' /etc/nginx/nginx.conf grep -Ri 'ssl_verify_client' /etc/nginx/nginx.conf Also inspect references to: auth_jwt auth_request ssl_client_certificate If JWT is in use, validate the config: auth_jwt_key_file /etc/nginx/jwt.pub; auth_jwt_require exp iat; Ensure the token includes expiration (exp) and ideally issued-at (iat) fields. If using mutual TLS: ssl_verify_client on; ssl_client_certificate /etc/nginx/certs/ca.pem; Ensure client-side certificate verification is required and the certificate authority (CA) trust is defined. If using auth_request: Ensure the upstream authentication server is enforcing replay resistance (such as nonce or short-lived tokens). Validate token behavior and session timeout logic. If no replay-resistant mechanism is found for network-based access, this is a finding.

ℹ️ Check

Determine the path to NGINX config file(s): nginx -qT | grep "# configuration" # configuration file /etc/nginx/nginx.conf: Note: The default NGINX configuration is "/etc/nginx/nginx.conf", though various files may also be included. Identify authentication mechanism in use by checking whether NGINX is configured to protect access to administrative interfaces or APIs: grep -Ri 'auth_' /etc/nginx/nginx.conf grep -Ri 'proxy_pass' /etc/nginx/nginx.conf grep -Ri 'ssl_verify_client' /etc/nginx/nginx.conf Also inspect references to: auth_jwt auth_request ssl_client_certificate If JWT is in use, validate the config: auth_jwt_key_file /etc/nginx/jwt.pub; auth_jwt_require exp iat; Ensure the token includes expiration (exp) and ideally issued-at (iat) fields. If using mutual TLS: ssl_verify_client on; ssl_client_certificate /etc/nginx/certs/ca.pem; Ensure client-side certificate verification is required and the certificate authority (CA) trust is defined. If using auth_request: Ensure the upstream authentication server is enforcing replay resistance (such as nonce or short-lived tokens). Validate token behavior and session timeout logic. If no replay-resistant mechanism is found for network-based access, this is a finding.

✔️ Fix
Implement a replay-resistant authentication method for any NGINX Plus resource that allows network access. Option A: JWT with expiration: Configure NGINX to use JWT authentication: auth_jwt "Protected"; auth_jwt_key_file /etc/nginx/keys/jwt_key.pub; auth_jwt_require exp iat; Ensure the token issuer includes a short-lived exp (e.g., less than five minutes) and iat claims. Option B: Mutual TLS: Enable client certificate authentication: ssl_verify_client on; ssl_client_certificate /etc/nginx/certs/client_ca.pem;

✔️ Fix

Implement a replay-resistant authentication method for any NGINX Plus resource that allows network access. Option A: JWT with expiration: Configure NGINX to use JWT authentication: auth_jwt "Protected"; auth_jwt_key_file /etc/nginx/keys/jwt_key.pub; auth_jwt_require exp iat; Ensure the token issuer includes a short-lived exp (e.g., less than five minutes) and iat claims. Option B: Mutual TLS: Enable client certificate authentication: ssl_verify_client on; ssl_client_certificate /etc/nginx/certs/client_ca.pem;