Don't perform security-impacting logic on client-side
If a security decision is ambiguous, perform it on the server. Client-side logic is not trustworthy.
OWASP Cheat Sheets · all subjects
architecture
161 notes in this subject, read out of this brain and free to use. This is page 1 of 3.
Don't rely on client-side business logic
Important business rules must be duplicated on the server side so a user cannot bypass them, which could lead to unexpected or costly behavior.
Don't rely on client-side security logic
The user controls client-side logic. Browser plugins allow setting breakpoints, skipping code, and changing values. Never rely on client-side logic for security decisions.
Layered defense architecture for anti-bot defenses
A single control is brittle; combine controls across three layers. Edge layer: CDN, WAF, or anti-bot service applies IP reputation, ASN filtering, TLS fingerprint (JA3/JA4), HTTP/2 fingerprint, and basic rate limits. Application layer: session-aware rate limits, identity-bound quotas, behavioral signals, honeypots, CAPTCHA challenges. Backend/business layer: anomaly detection on transactions, account-velocity rules, fraud scoring, async review queues. A request passing at one layer may still fail at another (e.g., 10 checkouts in 30 seconds with different cards).
Django X-Frame-Options header configuration
Include django.middleware.clickjacking.XFrameOptionsMiddleware in the MIDDLEWARE setting in settings.py, listed after django.middleware.security.SecurityMiddleware. Set X_FRAME_OPTIONS to 'DENY' or 'SAMEORIGIN' to protect against clickjacking attacks. This adds the X-Frame-Options header to all HTTP responses.
Django SECURE_CONTENT_TYPE_NOSNIFF header setting
Set SECURE_CONTENT_TYPE_NOSNIFF = True in settings.py using django.middleware.security.SecurityMiddleware to protect against MIME type sniffing attacks. This enables the X-Content-Type-Options: nosniff header.
Django CSRF_COOKIE_SECURE setting
Set CSRF_COOKIE_SECURE = True in settings.py to ensure the CSRF cookie is sent over secure connections only.
Django json_script template filter for JavaScript data
Use the json_script template filter to safely pass data to JavaScript in Django templates, which provides proper escaping and encoding.
Django CSRF token extraction for AJAX requests
For AJAX calls, the CSRF token for the request must be extracted prior to being used in the AJAX call.
Django admin panel URL obfuscation
Modify the default admin panel URL from the common example.com/admin/ to a custom path in the urls.py file. Modify the urlpatterns list so that the URL leading to admin.site.urls is different from 'admin/' to add an extra layer of security by obscuring the common endpoint.
Django check --deploy command for security verification
Run the built-in Django command 'check --deploy' to identify security misconfigurations. This command checks for issues like: DEBUG mode enabled, ALLOWED_HOSTS empty, SECURE_HSTS_SECONDS not set, SECURE_SSL_REDIRECT not set to True, SESSION_COOKIE_SECURE not set to True, CSRF_COOKIE_SECURE not set to True, SECRET_KEY insufficient complexity, and other security warnings.
Django custom cookie secure parameter
When setting a custom cookie in a view using HttpResponse.set_cookie(), set the secure parameter to True. Example: response.set_cookie('my_cookie', 'cookie_value', secure=True).
Django SESSION_COOKIE_SECURE setting
Set SESSION_COOKIE_SECURE = True in settings.py to ensure the session cookie is sent over secure (HTTPS) connections only.
Django Content Security Policy implementation
Django does not provide built-in Content Security Policy (CSP) support by default. CSP can be implemented using third-party libraries such as django-csp or by manually configuring HTTP response headers.
Django SECURE_SSL_REDIRECT setting
Set SECURE_SSL_REDIRECT = True in settings.py to ensure all communication is over HTTPS. This automatically redirects any HTTP requests to HTTPS with a 301 (permanent) redirect, which browsers will remember for subsequent requests.
Django dependencies update for security
Always keep Django and the application's dependencies up-to-date to address security vulnerabilities as they are discovered and patched.
Django CSRF middleware and csrf_token template tag
Include django.middleware.csrf.CsrfViewMiddleware in the MIDDLEWARE setting in settings.py to add CSRF related headers. In HTML forms, use the {% csrf_token %} template tag to include the CSRF token.
Django SECURE_PROXY_SSL_HEADER for proxied applications
If your Django application is behind a proxy or load balancer, set the SECURE_PROXY_SSL_HEADER setting so that Django can detect the original request's protocol.
Django template auto-escaping for XSS protection
Use Django's built-in template system with automatic HTML escaping to prevent XSS attacks. Refer to Django's Automatic HTML escaping documentation for details.
Django safe filter and mark_safe caution for XSS
Avoid using the safe filter or mark_safe function to disable Django's automatic template escaping. If necessary, ensure the input is from a trusted source. Extra caution is required when handling user-controlled inputs.
Django SECURE_HSTS_SECONDS header setting
Configure SECURE_HSTS_SECONDS in settings.py using django.middleware.security.SecurityMiddleware to ensure the site is only accessible via HTTPS.
Docker daemon socket /var/run/docker.sock is root entry point
The Docker socket /var/run/docker.sock is the UNIX socket that the Docker daemon listens to and the primary entry point for the Docker API. The owner of this socket is root. Giving someone access to it is equivalent to granting unrestricted root access to the host.
Keep host and Docker Engine up to date
Containers share the host's kernel. If the host kernel is vulnerable to privilege escalation exploits like Dirty COW, containers executing those exploits will still result in root access on the vulnerable host. Container escape vulnerabilities like Leaky Vessels typically result in the attacker gaining root access to the host. Regularly update both the host kernel and Docker Engine to protect against known vulnerabilities.
Docker misconfiguration detection tools
Use tools like inspec.io, dev-sec.io Docker baselines, or Docker Bench for Security to detect misconfigurations in Docker containers.
Mount volumes as read-only with :ro suffix
Mount volumes as read-only by appending :ro to the -v flag. Example: docker run -v volume-name:/path/in/container:ro alpine. Alternatively, use --mount with readonly parameter: docker run --mount source=volume-name,destination=/path/in/container,readonly alpine.
Kubernetes readOnlyRootFilesystem Security Context
In Kubernetes Security Context, set readOnlyRootFilesystem: true to mount the container's root filesystem as read-only.
Container scanning tools for vulnerability detection
Integrate container scanning tools into CI/CD pipelines to detect known vulnerabilities, secrets, and misconfigurations. Free tools include Clair, Grype, and Trivy. Commercial tools with free options include Snyk, Anchore, Docker Scout, and others. Tools detect issues and provide recommendations for fixes.
Kubernetes misconfiguration detection tools
Use tools like kubeaudit, kubesec.io, or kube-bench to detect misconfigurations in Kubernetes deployments.
Check Docker daemon log level with ps and grep
To check if the Docker daemon is running with a non-default log level, use: ps aux | grep '[d]ockerd.*--log-level' | awk '{for(i=1;i<=NF;i++) if ($i ~ /--log-level/) print $i}'.
Do not enable TCP Docker daemon socket
Running the docker daemon with -H tcp://0.0.0.0:XXX or similar exposes unencrypted and unauthenticated direct access to the Docker daemon. If the host is internet-connected, the docker daemon can be used by anyone from the public internet. If absolutely necessary, secure it according to Docker official documentation.
Docker Compose read_only configuration
In Docker Compose, set read_only: true in the service configuration to mount the filesystem as read-only. This is equivalent to the --read-only flag in docker run.
Run container with read-only filesystem using --read-only
Run containers with the --read-only flag to mount the filesystem as read-only. This prevents the application from modifying the filesystem. Example: docker run --read-only alpine sh -c 'echo "whatever" > /tmp'.
Limit processes with --ulimit nproc
Use --ulimit nproc=<number> to limit the maximum number of processes that can be created in a container. This prevents process fork bombs.
Limit file descriptors with --ulimit nofile
Use --ulimit nofile=<number> to limit the maximum number of open file descriptors in a container. This prevents file descriptor exhaustion attacks.
Docker Secrets for managing sensitive data
Use Docker Secrets to securely store and manage sensitive data such as passwords, tokens, and SSH keys. This prevents exposure of sensitive data in container images or runtime commands. Example: docker secret create my_secret /path/to/super-secret-data.txt, then docker service create --name web --secret my_secret nginx:latest.
Continuously monitor for anomalies in container activity
Monitor container processes, filesystem changes, and network activity in real time to identify abnormal patterns and detect potential security incidents early.
Use Falco, Tetragon, or Cilium eBPF for behavioral monitoring
Monitor container behavior at runtime using tools like Falco, Tetragon, or Cilium eBPF to detect unexpected or malicious activity such as unexpected exec calls, privilege escalation attempts, or unusual network connections.
SELinux for container labeling and policy enforcement
Enable SELinux on the host and ensure containers are labeled properly. Enforce SELinux policies to prevent unauthorized access to host resources from containers. Reference: SELinux Guide for Docker.
AppArmor profiles for mandatory access controls
Apply per-container AppArmor profiles to enforce mandatory access controls on container behavior. Reference: Docker AppArmor documentation.
Seccomp profile for restricting syscalls
Use seccomp profiles to restrict syscalls to the minimum required for the container. Use Docker's default seccomp profile as a starting point and customize per workload. Reference: Docker Seccomp documentation.
Do not disable default security profiles
Always start with Docker's or the host's default security profile as a baseline. Do not disable default security profiles as this removes important runtime security protections.
Use ufw-docker to enforce firewall rules over Docker
The ufw-docker project provides a script and supplemental iptables rules that patch Docker networking to respect UFW policies. After installing with sudo ufw-docker install, use standard UFW commands like sudo ufw-docker allow mycontainer 8000/tcp to control container traffic.
Rootless mode does not require root for installation
Docker rootless mode installation does not require root privileges, provided prerequisites are met. Refer to Docker documentation for prerequisites and installation instructions.
Bind published ports to localhost only
To safely publish container ports, bind the host side to 127.0.0.1 so the service is only reachable locally. Example: docker run -p 127.0.0.1:8000:8000 myimage. In Docker Compose: ports: ["127.0.0.1:8000:8000"]. This prevents unintended exposure on all interfaces.
Docker bypasses UFW firewall rules
Docker manages its own iptables and nftables rules directly and bypasses UFW (Uncomplicated Firewall) entirely. When publishing a port with -p 8000:8000, Docker inserts iptables rules that open the port to all interfaces and source addresses, typically before explicit firewall DENY rules. This can unintentionally expose container services to the public internet.
Limit container restart attempts with --restart=on-failure
Use --restart=on-failure:<number_of_restarts> to limit the maximum number of times a container will automatically restart. This prevents restart-based DoS attacks.
Configure inter-container connectivity with custom networks
Inter-Container Connectivity (icc) is enabled by default, allowing all containers to communicate via the docker0 bridged network. Instead of disabling it entirely with --icc=false, create custom Docker networks and specify which containers should attach to them for more granular control.
Kubernetes allowPrivilegeEscalation false setting
In Kubernetes Security Context, set allowPrivilegeEscalation: false to prevent containers from gaining new privileges. Example: securityContext: allowPrivilegeEscalation: false.
Do not run Docker daemon at debug log level
Set an appropriate log level on the Docker daemon. A base log level of info and above captures necessary logs. Do not run the docker daemon at debug log level unless specifically required, as it increases log verbosity and may expose sensitive information.
Combine --read-only with --tmpfs for temporary writes
If an application must write temporary files, combine --read-only with --tmpfs to mount a temporary filesystem. Example: docker run --read-only --tmpfs /tmp alpine sh -c 'echo "whatever" > /tmp/file'.
Prevent privilege escalation with --security-opt=no-new-privileges
Always run Docker images with --security-opt=no-new-privileges to prevent containers from gaining new privileges via setuid or setgid binaries. This prevents in-container privilege escalation attacks.
Kubernetes Security Context capabilities configuration
In Kubernetes, configure container capabilities in the Security Context using the capabilities field with drop and add lists. Example: securityContext: capabilities: drop: [ALL], add: [CHOWN]. The Restricted pod security standard can be configured for hardened defaults.
Drop all Linux capabilities and add only required ones
Linux kernel capabilities are privileges used by privileged processes. The most secure setup is to drop all capabilities using --cap-drop all, then add only the capabilities required by the container using --cap-add. Example: docker run --cap-drop all --cap-add CHOWN alpine. Do not run containers with the --privileged flag as it adds ALL Linux kernel capabilities.
Dockerfile lint checks for security
Add a security linter as a step in the CI/CD build pipeline to check Dockerfile best practices including: USER directive is specified, base image version is pinned, OS package versions are pinned, ADD is avoided in favor of COPY, and curl bash patterns are avoided in RUN directives.
Do not mount Docker socket to containers
Do not mount /var/run/docker.sock to containers using -v /var/run/docker.sock:/var/run/docker.sock or equivalent Docker Compose volumes configuration. Mounting the socket read-only is not a solution as it only makes exploitation harder. This applies to both docker run commands and compose files.
Secret detection tools for container images
Use tools like ggshield (open source with free option), Gitleaks (open source), or TruffleHog (open source) to detect secrets accidentally committed in container images.
Rootless mode runs Docker daemon as unprivileged user
In rootless mode, the Docker daemon and containers run as an unprivileged user. If an attacker breaks out of the container, they will not have root privileges on the host, substantially limiting the attack surface. This differs from userns-remap mode where the daemon still operates with root privileges.
Docker daemon default logging level is info
The Docker daemon is configured with a default logging level of info, which can be verified in /etc/docker/daemon.json by checking the log-level key. If not present, info is the default. A log level of info and above captures all logs except debug logs.
Evaluate security posture before enabling rootless mode
Consider specific requirements and security posture of your environment before enabling rootless mode. For environments where security is paramount and rootless mode limitations do not interfere with operational requirements, it is strongly recommended. Alternatively, consider Podman as an alternative to Docker.
Docker Compose secrets configuration
In Docker Compose, define secrets in the top-level secrets section and reference them in services. Example: version: "3.8", secrets: my_secret: file: ./super-secret-data.txt, services: web: image: nginx:latest, secrets: [my_secret].