OWASP CRS Docker Image

What is the OWASP CRS

OWASP CRS is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls. ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx.

Supported Tags

Stable Tags

Stable Tags are composed of:

• CRS version, in the format <major>[.<minor>[.<patch]]
• web server variant
• OS variant (optional, nginx only)
• writable (optional)
• date, in the format YYYYMMDDHHMM

The stable tag format is <CRS version>-<web server>[-<os>][-<writable>]-<date>. Examples (do not blindly copy these labels):

• 4-nginx-202509051009
• 4.18-nginx-202509051009
• 4.18.0-nginx-202509051009 Or for the previous major release:
• 3-nginx-alpine-202509051009
• 3.3-nginx-alpine-202509051009
• 3.3.7-nginx-alpine-202509051009

Rolling Tags

Rolling tags are updated whenever a new stable tag release occurs. Rolling tags can be practical but should not be used in production.

Rolling Tags are composed of:

• web server variant
• OS variant (optional)
• writable (optional, nginx only)

The stable tag format is <web server>[-<os>][-<writable>]. Examples:

• nginx
• apache-alpine

LTS Tags

LTS (Long-Term Support) tags are stable tags pointing to a designated LTS release. They are updated less frequently than stable tags and are intended for users who prioritize stability over new features.

LTS Tags are composed of:

• CRS version, in the format <minor> or <minor>.<patch>
• web server variant
• OS variant (optional)
• lts suffix

The LTS tag format is <CRS version>-<web server>[-<os>]-lts. Examples:

• 4.25-nginx-lts
• 4.25.0-nginx-lts
• 4.25-apache-lts
• 4.25.0-apache-alpine-lts

OS Variants

• nginx – latest stable ModSecurity v3 on Nginx 1.30.1 official stable base image, and latest stable OWASP CRS 4.27.0
  • nginx
  • nginx-alpine
• Apache httpd – last stable ModSecurity v2 on Apache 2.4.67 official stable base image, and latest stable OWASP CRS 4.27.0
  • apache
  • apache-alpine

Read-only Root Filesystem

By default, the root filesystem of our containers are writable. We also provide images that are set up to run on a read-only filesystem for enhanced security.

Examples:

• nginx-read-only
• nginx-alpine-read-only

Notes regarding Openresty version of this image

• The version was removed as no maintainer was found.

Supported architectures

Our builds are based on the official Apache httpd, nginx and Openresty images, which means we can only support the architectures they support.

We currently provide images for the following architectures:

• linux/amd64
• linux/arm64
• linux/i386

Building

If you want to see the targets of the build, use:

docker buildx bake -f ./docker-bake.hcl --print

To build for any platforms of your choosing, just use this example:

docker buildx create --use --platform linux/amd64,linux/i386,linux/arm64
docker buildx bake -f docker-bake.hcl

To build a specific target for a single platform only (replace target and platform strings in the example with your choices):

docker buildx bake -f docker-bake.hcl --set "*.platform=linux/amd64" nginx-alpine-writable

Notes regarding Openresty version of the image

Openresty image builds currently support only these architectures:

• linux/amd64
• linux/arm64

Container Health Checks

🆕 We add healthchecks to the images, so that containers return HTTP status code 200 from the /healthz endpoint. When a container has a healthcheck specified, it has a health status in addition to its normal status. This status is initially starting. Whenever a health check passes, it becomes healthy (whatever state it was previously in). After a certain number of consecutive failures, it becomes unhealthy. See https://docs.docker.com/engine/reference/builder/#healthcheck for more information.

CRS Versions

Hey, I used some specific git version with the containers? What happened?

You can achieve the same results just by getting any version you want, and using docker volumes. See this example:

git clone https://github.com/coreruleset/coreruleset.git myrules
cd myrules
git checkout ac2a0d1
docker run -p 8080:8080 -ti -e BLOCKING_PARANOIA=4 -v rules:/opt/owasp-crs/rules:ro --rm owasp/modsecurity-crs

Quick reference

• Where to get help: the OWASP CRS container repo, the OWASP CRS Slack channel (#coreruleset on owasp.slack.com), or Stack Overflow

• Where to file issues: the OWASP CRS container repo

• Maintained By: The CRS project maintainers

What is ModSecurity

ModSecurity is an open source, cross platform Web Application Firewall (WAF) engine for Apache, IIS and Nginx. It has a robust event-based programming language which provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis.

SSL files naming breaking change

SSL related variables have been renamed to highlight they are a path to a file, so docker doesn't complain about sensitive usage in the case of variables ending in _KEY.

Nginx based images breaking change

If using the Nginx environment variables is not enough for your use case, you can mount your own nginx.conf file as the new template for generating the base config.

An example can be seen in the docker-compose file.

💬 What happens if I want to make changes in a different file, like /etc/nginx/conf.d/default.conf? You mount your local file, e.g. nginx/default.conf as the new template: /etc/nginx/templates/conf.d/default.conf.template. You can do this similarly with other files. Files in the templates directory will be copied and subdirectories will be preserved.

Both nginx and httpd containers now run with an unprivileged user. This means that we cannot bind to ports below 1024, so you might need to correct your PORT and SSL_PORT settings. Now the defaults for both nginx and httpd are 8080 and 8443.

Nginx port_in_redirect breaking change

Previously, nginx's default port_in_redirect on caused the internal listening port (e.g., 8080 or 8443) to be included in redirect Location headers (e.g., when nginx adds a trailing slash: /address → http://example.com:8080/address/). This broke setups where the container is behind a reverse proxy and the external port differs from the internal port.

With port_in_redirect off (the default), nginx omits the port from redirect URLs, so clients follow redirects using the correct external port. If you relied on the port being included in nginx-generated redirects, set NGINX_PORT_IN_REDIRECT=on.

Common ENV Variables

These variables are common to image variants and will set defaults based on the image name.

Apache ENV Variables

Nginx ENV Variables

Openresty ENV Variables

Openresty uses the same environment variables as the nginx version.

ModSecurity ENV Variables

All these variables impact in configuration directives in the modsecurity engine running inside the container. The reference manual has the extended documentation, and for your reference we list the specific directive we change when you modify the ENV variables for the container.

CRS specific

TLS/HTTPS

docker build -t my-modsec .
docker run -p 8443:8443 my-modsec

TLS is configured on port 8443 and enabled by default.

We use sane intermediate defaults taken from the Mozilla SSL config tool. Please review the defaults and choose the ones that best match your needs.

You can set the *_ALWAYS_TLS_REDIRECT environment variables to always redirect from http to https.

Proxy Configuration

The owasp/modsecurity-crs container images in their default configuration (i.e., without manual changes to / overrides of configuration files) act as reverse proxies and require a running backend at the address specified through the BACKEND environment variable.

ModSecurity is often used in a reverse proxy setup with the following properties:

• reverse proxy acts as public end point
• reverse proxy performs TLS termination (necessary for ModSecurity to inspect content)
• ModSecurity runs on the reverse proxy to filter traffic
• only benign traffic is passed to the backend

This allows one to use ModSecurity without modifying the webserver hosting the underlying application and also protects web servers that ModSecurity cannot currently be embedded into.

Tips:

• the application web server (the one receiving traffic from the reverse proxy) should not listen on a public interface. Only the reverse proxy should be exposed to the public. With Docker, this could mean setting up a network for both containers and only exposing the reverse proxy with -p 8080:8080, for example. docker compose takes care of this automatically. See the docker-compose.yaml for an example setup.

docker build -t my-modsec . -f
docker run -p 8080:8080 -e BACKEND=http://example.com my-modsec

ServerName

It is often convenient to set your server name (set to localhost by default). To do this simply use the SERVER_NAME environment variable.

docker build -t modsec .
docker run -p 8080:8080 -e SERVER_NAME=myhost my-modsec

ModSecurity CRS Tuning

There are two possible ways to pass ModSecurity CRS tuning rules to the container:

• To map the ModSecurity tuning file(s) via volumes into the container during the run command
• To copy the ModSecurity tuning file(s) into the created container and then start the container

Map ModSecurity tuning file via volume

docker run -dti --rm \
   -p 8080:8080 \
   -v /path/to/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf:/etc/modsecurity.d/owasp-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf \
   -v /path/to/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf:/etc/modsecurity.d/owasp-crs/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf \
   owasp/modsecurity-crs:apache

Copy ModSecurity tuning file into created container

This example can be helpful when no volume mounts are possible (some CI pipelines).

docker create -ti --name modseccrs \
   -p 8080:8080 \
   owasp/modsecurity-crs:apache

docker cp /path/to/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf \
   modseccrs:/etc/modsecurity.d/owasp-crs/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf

docker start modseccrs

Full docker run example of possible setup

The following example illustrates how to use docker run with some of the variables. Its purpose is illustration only and it should not be used to run a container in production.

Some important things to note:

• Error and audit logs are enabled and mapped to files on the host, so that their contents are accessible and don't pollute the container filesystem. Docker requires these files to exist, otherwise they would be created as directories, hence the use of the touch ... commands.
• For containers with read-only filesystems, the volumes might have to be specified differently, e.g., using tmpfs. Alternatively, if only one log output is required, the output could be redirected to stdout (/proc/self/fd/2).
• The example expects a backend web server to be running at localhost:8081.

touch /tmp/host-fs-auditlog.log
touch /tmp/host-fs-errorlog.log
docker run \
   -dti \
   -p 8080:8080 \
   --rm \
   -v /tmp/host-fs-auditlog.log:/var/log/modsec_audit.log \
   -v /tmp/host-fs-errorlog.log:/var/log/modsec_error.log \
   -e MODSEC_AUDIT_ENGINE=on \
   -e MODSEC_AUDIT_LOG=/var/log/modsec_audit.log \
   -e LOGLEVEL=warn \
   -e ERRORLOG=/var/log/modsec_error.log \
   -e BLOCKING_PARANOIA=2 \
   -e DETECTION_PARANOIA=2 \
   -e ENFORCE_BODYPROC_URLENCODED=1 \
   -e ANOMALY_INBOUND=10 \
   -e ANOMALY_OUTBOUND=5 \
   -e ALLOWED_METHODS="GET POST PUT" \
   -e ALLOWED_REQUEST_CONTENT_TYPE="text/xml|application/xml|text/plain" \
   -e ALLOWED_REQUEST_CONTENT_TYPE_CHARSET="utf-8|iso-8859-1" \
   -e ALLOWED_HTTP_VERSIONS="HTTP/1.1 HTTP/2 HTTP/2.0" \
   -e RESTRICTED_EXTENSIONS=".cmd/ .com/ .config/ .dll/" \
   -e RESTRICTED_HEADERS="/proxy/ /if/" \
   -e STATIC_EXTENSIONS="/.jpg/ /.jpeg/ /.png/ /.gif/" \
   -e MAX_NUM_ARGS=128 \
   -e ARG_NAME_LENGTH=50 \
   -e ARG_LENGTH=200 \
   -e TOTAL_ARG_LENGTH=6400 \
   -e MAX_FILE_SIZE=100000 \
   -e COMBINED_FILE_SIZES=1000000 \
   -e TIMEOUT=60 \
   -e SERVER_ADMIN=root@localhost \
   -e SERVER_NAME=localhost \
   -e PORT=8080 \
   -e MODSEC_RULE_ENGINE=on \
   -e MODSEC_REQ_BODY_ACCESS=on \
   -e MODSEC_REQ_BODY_LIMIT=13107200 \
   -e MODSEC_REQ_BODY_NOFILES_LIMIT=131072 \
   -e MODSEC_RESP_BODY_ACCESS=on \
   -e MODSEC_RESP_BODY_LIMIT=524288 \
   -e MODSEC_PCRE_MATCH_LIMIT=1000 \
   -e MODSEC_PCRE_MATCH_LIMIT_RECURSION=1000 \
   -e VALIDATE_UTF8_ENCODING=1 \
   -e CRS_ENABLE_TEST_MARKER=1 \
   -e BACKEND="http://localhost:8081" \
   owasp/modsecurity-crs:apache

Kubernetes

:warning: If you see this error in your k8s deployment logs:

...
/docker-entrypoint.d/20-envsubst-on-templates.sh: 53: envsubst: Argument list too long

This happens because kubernetes is injecting service related environment variables. Adding enableServiceLinks: false in your pod spec, solves the problem:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 1
  template:
    spec:
      enableServiceLinks: false
      containers:
        - name: my-container
          image: owasp/modsecurity-crs:4.8.0-nginx-202411071011