Application Security Best Practices
While ARMORRED provides hardened container images with reduced attack surface and strengthened defenses, the security of the application layer remains the responsibility of the user. A hardened container running a vulnerable or misconfigured application still presents risk.
The starting point for securing applications consists of hardening guides specific to the application, programming language, or framework that will execute in the containerized environment. Organizations such as NIST1 , OWASP,2 and CIS (Center for Internet Security)3 publish detailed configuration benchmarks for common technologies. These guides address implementation-specific vulnerabilities and configuration options that generic security guidance cannot cover.
Modern application deployments involve multiple technology layers, each requiring dedicated security configuration. A Java Spring application, for instance, demands attention at the runtime level (JVM settings), the framework level (Spring configuration), the security framework level (Spring Security), and finally the application code itself. Vulnerabilities at any layer can compromise the entire system regardless of protections elsewhere.
For example, deploying a Java application benefits from the OWASP Java Security Cheat Sheet4 and CIS benchmarks for the JVM,5 while a Python web application should reference the OWASP Python Security guidelines6 and framework-specific documentation for Django7 or Flask.8 Node.js applications should consult the OWASP NodeJS Security Cheat Sheet.9 Database administrators should consult CIS benchmarks for PostgreSQL,10 MySQL,11 or their specific database system. These specialized resources provide actionable configuration guidance tested against real-world attack scenarios.
Transport Layer Security
Without encryption, data transmitted over networks can be intercepted, read, and modified by attackers through man-in-the-middle attacks. Transport Layer Security (TLS) provides confidentiality, integrity, and authentication for network communications. Even within private networks and container orchestration environments, TLS should be used to protect against lateral movement by attackers who have gained initial access. The National Institute of Standards and Technology provides comprehensive guidance on TLS implementation.12
Protocol Version Requirements
| Version | Status |
|---|---|
| TLS 1.3 | Recommended (improved security and performance) |
| TLS 1.2 | Minimum acceptable |
| TLS 1.1 | Deprecated - must not be used |
| TLS 1.0 | Deprecated - must not be used |
TLS 1.3 removes legacy cryptographic algorithms and provides improved performance through reduced handshake round-trips.
Cipher Suite Configuration
Disable weak cipher suites and prioritize those providing forward secrecy:
| Category | Recommendation |
|---|---|
| Key Exchange | ECDHE (preferred), DHE |
| Symmetric | AES-GCM, ChaCha20-Poly1305 |
| Avoid | CBC mode ciphers |
| Disable | NULL, EXPORT, DES, RC4, MD5-based suites |
Certificate Management
| Practice | Description |
|---|---|
| Trusted CA | Use certificates from recognized authorities |
| Automated renewal | Implement ACME protocol (Let's Encrypt) |
| Expiration monitoring | Alert before certificate expiration |
| Certificate pinning | Consider for high-security applications |
HTTP Strict Transport Security
Enable HSTS to prevent protocol downgrade attacks:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Cryptography
Cryptographic controls protect data confidentiality and integrity when information is stored or processed. Weak or deprecated algorithms can be exploited by attackers with sufficient computational resources, potentially exposing sensitive data even when encryption was applied. Applications must use cryptographic algorithms approved by NIST for protecting sensitive data, following the guidelines for algorithm selection and key management.1314
Approved Algorithms
| Purpose | Recommended | Minimum Acceptable |
|---|---|---|
| Symmetric | AES-256-GCM | AES-128-GCM |
| Hashing | SHA-384, SHA-512 | SHA-256 |
| Key Exchange | ECDH P-384, X25519 | ECDH P-256, DH 2048-bit |
| Digital Signature | ECDSA P-384, Ed25519 | ECDSA P-256, RSA 2048 |
Deprecated Algorithms
The following must not be used for security purposes:
| Algorithm | Vulnerability |
|---|---|
| MD5 | Collision attacks |
| SHA-1 | Collision attacks |
| DES | Insufficient key length (56-bit) |
| 3DES | Insufficient key length, slow |
| RC4 | Statistical biases |
| RSA < 2048 bits | Factorization attacks |
Key Management
| Practice | Description |
|---|---|
| Secure generation | Use cryptographically secure RNG |
| Separation | Store keys separately from encrypted data |
| Rotation | Implement scheduled key rotation |
| Hardware protection | Use HSMs for high-value keys |
| Transmission | Never transmit keys in plaintext |
Authentication and Credential Management
Identity verification is the foundation of access control. Compromised credentials remain a leading cause of security breaches, with attackers using stolen passwords, credential stuffing attacks, and social engineering to gain unauthorized access. Proper authentication implementation includes secure password handling, multi-factor authentication for sensitive operations, and robust session management. Authentication mechanisms must follow current NIST Digital Identity Guidelines, which have evolved significantly to reflect modern threat landscapes and usability research.15
Password Policies
Modern guidance emphasizes password length over complexity:
| Policy | Recommendation |
|---|---|
| Minimum length | 8 characters (12+ recommended) |
| Maximum length | At least 64 characters |
| Composition rules | Not required (no forced mixed case/symbols) |
| Periodic rotation | Not required (change only on compromise) |
| Breached password check | Required (reject known compromised passwords) |
Password Storage
Never store passwords in plaintext. Use memory-hard hashing algorithms:
| Algorithm | Recommendation | Parameters |
|---|---|---|
| Argon2id | Preferred | m=65536, t=3, p=4 |
| bcrypt | Acceptable | cost factor 10+ |
| scrypt | Acceptable | N=32768, r=8, p=1 |
| PBKDF2 | Legacy | SHA-256, 600,000+ rounds |
Multi-Factor Authentication
Implement MFA for privileged access and sensitive operations:
| Method | Security Level | Notes |
|---|---|---|
| Hardware keys | Highest | FIDO2/WebAuthn |
| TOTP authenticators | High | Time-based one-time passwords |
| Push notifications | Medium | App-based approval |
| SMS OTP | Low | Avoid (SIM swapping risk) |
Session Management
| Practice | Description |
|---|---|
| Secure generation | Use cryptographically secure random IDs |
| Regeneration | New session ID after authentication |
| Timeouts | Implement absolute and idle timeouts |
| Invalidation | Server-side invalidation on logout |
Input Validation and Output Encoding
Applications receive data from many sources: user input, APIs, databases, files, and external services. Any data originating outside the application's trust boundary must be treated as potentially malicious. Injection attacks exploit insufficient validation to execute unintended commands, access unauthorized data, or compromise system integrity. SQL injection,16 cross-site scripting,17 and command injection18 remain prevalent attack vectors despite being well-understood. All data crossing trust boundaries must be validated, and input validation failures are consistently among the most exploited vulnerability classes.1920
Validation Principles
| Principle | Description |
|---|---|
| Server-side | Client-side validation is for usability only |
| Allowlists | Prefer allowlists over denylists |
| Type checking | Validate data type, length, format, range |
| Rejection | Reject invalid input; do not sanitize |
Related Weaknesses
The following Common Weakness Enumerations (CWEs) relate to input validation and output encoding vulnerabilities:212223
| CWE | Name | Description |
|---|---|---|
| CWE-20 | Improper Input Validation | Failure to validate input properties |
| CWE-79 | Cross-site Scripting (XSS) | Output not properly encoded for web |
| CWE-89 | SQL Injection | Input not neutralized in SQL commands |
| CWE-78 | OS Command Injection | Input not neutralized in OS commands |
| CWE-94 | Code Injection | Input allows arbitrary code execution |
| CWE-116 | Improper Encoding/Escaping | Output encoding failures |
Web Application Security
Web applications face unique threats due to their exposure on public networks and interaction with untrusted clients through browsers. Attackers exploit browser behaviors, cross-origin requests, and client-side state to perform attacks that traditional network security cannot prevent. Security headers instruct browsers to enforce protections, cookies require specific attributes to prevent theft, and cross-origin policies must be carefully configured. Web applications require additional security controls beyond general application hardening to address these browser-specific attack vectors.
Security Headers
Configure the following HTTP response headers:
| Header | Value |
|---|---|
| Content-Security-Policy | default-src 'self'; script-src 'self' |
| X-Content-Type-Options | nosniff |
| X-Frame-Options | DENY |
| Referrer-Policy | strict-origin-when-cross-origin |
| Permissions-Policy | geolocation=(), microphone=(), camera=() |
Content-Security-Policy prevents cross-site scripting by controlling resource loading. Start restrictive and relax as needed.24
Cookie Security
Set appropriate attributes on all cookies:
| Attribute | Purpose | Recommended Value |
|---|---|---|
| Secure | Transmit only over HTTPS | Always set |
| HttpOnly | Prevent JavaScript access | Always set |
| SameSite | Mitigate CSRF | Strict or Lax |
| Path | Limit cookie scope | Restrictive |
| Domain | Restrict to specific domain | Explicit |
Cross-Origin Resource Sharing
| Configuration | Recommendation |
|---|---|
| Allowed origins | Specify exact origins (no wildcard in prod) |
| Allowed methods | Limit to required methods only |
| Allowed headers | Restrict to necessary headers |
| Max-age | Set appropriate preflight cache duration |
Cross-Site Request Forgery Protection
| Control | Description |
|---|---|
| Synchronizer tokens | Include CSRF token in forms |
| Double-submit cookies | Alternative token pattern |
| Header verification | Check Origin and Referer headers |
| SameSite cookies | Set SameSite attribute |
API Security
RESTful APIs require specific considerations:25
| Control | Description |
|---|---|
| Rate limiting | Prevent abuse and DoS |
| Authentication | OAuth 2.0 or OpenID Connect26 |
| JWT validation | Verify signature, issuer, audience, expiration |
| Versioning | Manage breaking changes |
| Status codes | Return appropriate HTTP status codes |
| URL security | Avoid sensitive data in URLs |
Security Testing and Scanning
Security vulnerabilities discovered late in development or after deployment are significantly more costly to remediate than those found early. Shifting security testing left in the development lifecycle enables teams to identify and fix issues before they reach production. Multiple testing approaches provide defense in depth: static analysis examines source code without execution, dynamic analysis tests running applications, and composition analysis identifies vulnerabilities in dependencies. Integrate security testing throughout the development lifecycle to catch vulnerabilities at every stage.27
Static Application Security Testing (SAST)
Analyze source code for vulnerabilities before deployment:
| Language | Tools |
|---|---|
| Python | Bandit, Pylint security plugins |
| JavaScript | ESLint security plugins, Semgrep |
| Go | gosec, staticcheck |
| Java | SpotBugs, PMD, SonarQube |
| C/C++ | Clang Static Analyzer, Coverity |
| Rust | cargo-audit, clippy |
Dynamic Application Security Testing (DAST)
Test running applications for vulnerabilities:
| Tool | Type | Description |
|---|---|---|
| OWASP ZAP | Open source | Comprehensive web app scanner |
| Burp Suite | Commercial | Professional penetration testing |
| Nikto | Open source | Web server scanner |
| sqlmap | Open source | SQL injection detection |
Software Composition Analysis (SCA)
Identify vulnerabilities in dependencies:
Logging and Monitoring
Prevention controls will eventually fail, making detection and response capabilities essential. Comprehensive logging provides the forensic data needed to investigate incidents, identify attack patterns, and demonstrate compliance with security requirements. Without adequate logging, organizations cannot detect ongoing attacks, understand their scope, or learn from security incidents. However, logs themselves can become a security risk if they contain sensitive data. Security-relevant events must be logged for incident detection and response while carefully excluding credentials and other sensitive information.28
Events to Log
| Event Category | Examples |
|---|---|
| Authentication | Login success/failure, logout, MFA events |
| Authorization | Access denied, privilege escalation |
| Input validation | Rejected input, malformed requests |
| Application errors | Exceptions, crashes, unexpected states |
| Administrative actions | Configuration changes, user management |
| Data operations | Access to sensitive data, modifications |
Logging Best Practices
| Practice | Description |
|---|---|
| Structured format | Use JSON for machine parsing |
| Timestamps | UTC with millisecond precision |
| Context | Include sufficient detail without secrets |
| Integrity | Append-only storage, consider signing |
| Retention | Define retention periods per regulations |
Sensitive Data to Exclude
Never log the following:
| Data Type | Reason |
|---|---|
| Passwords | Authentication credentials |
| Session tokens | Session hijacking risk |
| API keys | Unauthorized access risk |
| Credit card numbers | PCI-DSS compliance |
| Health information | HIPAA compliance |
| Cryptographic keys | Complete security compromise |
Secrets Management
Credentials, API keys, database passwords, and cryptographic keys are high-value targets for attackers. Secrets committed to version control, hardcoded in source code, or stored in plaintext configuration files are routinely discovered through automated scanning and repository analysis. Once exposed, secrets can provide immediate access to production systems, databases, and cloud infrastructure. Proper secrets management involves secure storage, controlled access, regular rotation, and audit logging. Credentials and cryptographic keys require careful handling throughout their lifecycle to prevent unauthorized disclosure.29
Storage Principles
Never commit secrets to version control or hardcode in application code.
| Solution | Use Case |
|---|---|
| HashiCorp Vault | Enterprise secrets management |
| AWS Secrets Manager | AWS-native applications |
| Azure Key Vault | Azure-native applications |
| GCP Secret Manager | GCP-native applications |
| Kubernetes Secrets | Container orchestration (encrypt at rest) |
Environment Variables
For containerized applications, inject secrets via environment variables or mounted files:
Rotation
| Practice | Description |
|---|---|
| Scheduled rotation | Rotate on defined schedule |
| Compromise response | Immediate rotation on suspected breach |
| Zero-downtime | Implement graceful rotation procedures |
| Audit trails | Maintain logs of rotation events |
References
Security and Privacy Controls for Information Systems and Organizations - NIST SP 800-53 Rev. 5. https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
OWASP Cheat Sheet Series - OWASP. https://cheatsheetseries.owasp.org/
CIS Benchmarks - Center for Internet Security. https://www.cisecurity.org/cis-benchmarks
Java Security Cheat Sheet - OWASP. https://cheatsheetseries.owasp.org/cheatsheets/Java_Security_Cheat_Sheet.html
CIS Oracle Java Benchmark - Center for Internet Security. https://www.cisecurity.org/benchmark/java
Python Security Cheat Sheet - OWASP. https://cheatsheetseries.owasp.org/cheatsheets/Python_Security_Cheat_Sheet.html
Django Security Documentation - Django Software Foundation. https://docs.djangoproject.com/en/stable/topics/security/
Flask Security Considerations - Pallets Projects. https://flask.palletsprojects.com/en/stable/security/
NodeJS Security Cheat Sheet - OWASP. https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html
CIS PostgreSQL Benchmark - Center for Internet Security. https://www.cisecurity.org/benchmark/postgresql
CIS MySQL Benchmark - Center for Internet Security. https://www.cisecurity.org/benchmark/mysql
Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations - NIST SP 800-52 Rev. 2. https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final
Transitioning the Use of Cryptographic Algorithms and Key Lengths - NIST SP 800-131A Rev. 2. https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final
Guideline for Using Cryptographic Standards in the Federal Government - NIST SP 800-175B Rev. 1. https://csrc.nist.gov/publications/detail/sp/800-175b/rev-1/final
Digital Identity Guidelines: Authentication and Lifecycle Management - NIST SP 800-63B. https://pages.nist.gov/800-63-3/sp800-63b.html
CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') - MITRE. https://cwe.mitre.org/data/definitions/89.html
CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - MITRE. https://cwe.mitre.org/data/definitions/79.html
CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - MITRE. https://cwe.mitre.org/data/definitions/78.html
CWE-20: Improper Input Validation - MITRE. https://cwe.mitre.org/data/definitions/20.html
Input Validation Cheat Sheet - OWASP. https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
Cross Site Scripting Prevention Cheat Sheet - OWASP. https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
SQL Injection Prevention Cheat Sheet - OWASP. https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
CWE-116: Improper Encoding or Escaping of Output - MITRE. https://cwe.mitre.org/data/definitions/116.html
Content Security Policy Cheat Sheet - OWASP. https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
REST Security Cheat Sheet - OWASP. https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
The OAuth 2.0 Authorization Framework - IETF RFC 6749. https://datatracker.ietf.org/doc/html/rfc6749
Security and Privacy Controls for Information Systems and Organizations, SA-11 - NIST SP 800-53 Rev. 5. https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
Guide to Computer Security Log Management - NIST SP 800-92. https://csrc.nist.gov/publications/detail/sp/800-92/final
The Twelve-Factor App - Adam Wiggins. https://12factor.net/config