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

VersionStatus
TLS 1.3Recommended (improved security and performance)
TLS 1.2Minimum acceptable
TLS 1.1Deprecated - must not be used
TLS 1.0Deprecated - 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:

CategoryRecommendation
Key ExchangeECDHE (preferred), DHE
SymmetricAES-GCM, ChaCha20-Poly1305
AvoidCBC mode ciphers
DisableNULL, EXPORT, DES, RC4, MD5-based suites

Certificate Management

PracticeDescription
Trusted CAUse certificates from recognized authorities
Automated renewalImplement ACME protocol (Let's Encrypt)
Expiration monitoringAlert before certificate expiration
Certificate pinningConsider 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

PurposeRecommendedMinimum Acceptable
SymmetricAES-256-GCMAES-128-GCM
HashingSHA-384, SHA-512SHA-256
Key ExchangeECDH P-384, X25519ECDH P-256, DH 2048-bit
Digital SignatureECDSA P-384, Ed25519ECDSA P-256, RSA 2048

Deprecated Algorithms

The following must not be used for security purposes:

AlgorithmVulnerability
MD5Collision attacks
SHA-1Collision attacks
DESInsufficient key length (56-bit)
3DESInsufficient key length, slow
RC4Statistical biases
RSA < 2048 bitsFactorization attacks

Key Management

PracticeDescription
Secure generationUse cryptographically secure RNG
SeparationStore keys separately from encrypted data
RotationImplement scheduled key rotation
Hardware protectionUse HSMs for high-value keys
TransmissionNever 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:

PolicyRecommendation
Minimum length8 characters (12+ recommended)
Maximum lengthAt least 64 characters
Composition rulesNot required (no forced mixed case/symbols)
Periodic rotationNot required (change only on compromise)
Breached password checkRequired (reject known compromised passwords)

Password Storage

Never store passwords in plaintext. Use memory-hard hashing algorithms:

AlgorithmRecommendationParameters
Argon2idPreferredm=65536, t=3, p=4
bcryptAcceptablecost factor 10+
scryptAcceptableN=32768, r=8, p=1
PBKDF2LegacySHA-256, 600,000+ rounds

Multi-Factor Authentication

Implement MFA for privileged access and sensitive operations:

MethodSecurity LevelNotes
Hardware keysHighestFIDO2/WebAuthn
TOTP authenticatorsHighTime-based one-time passwords
Push notificationsMediumApp-based approval
SMS OTPLowAvoid (SIM swapping risk)

Session Management

PracticeDescription
Secure generationUse cryptographically secure random IDs
RegenerationNew session ID after authentication
TimeoutsImplement absolute and idle timeouts
InvalidationServer-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

PrincipleDescription
Server-sideClient-side validation is for usability only
AllowlistsPrefer allowlists over denylists
Type checkingValidate data type, length, format, range
RejectionReject invalid input; do not sanitize

Related Weaknesses

The following Common Weakness Enumerations (CWEs) relate to input validation and output encoding vulnerabilities:212223

CWENameDescription
CWE-20Improper Input ValidationFailure to validate input properties
CWE-79Cross-site Scripting (XSS)Output not properly encoded for web
CWE-89SQL InjectionInput not neutralized in SQL commands
CWE-78OS Command InjectionInput not neutralized in OS commands
CWE-94Code InjectionInput allows arbitrary code execution
CWE-116Improper Encoding/EscapingOutput 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:

HeaderValue
Content-Security-Policydefault-src 'self'; script-src 'self'
X-Content-Type-Optionsnosniff
X-Frame-OptionsDENY
Referrer-Policystrict-origin-when-cross-origin
Permissions-Policygeolocation=(), 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:

AttributePurposeRecommended Value
SecureTransmit only over HTTPSAlways set
HttpOnlyPrevent JavaScript accessAlways set
SameSiteMitigate CSRFStrict or Lax
PathLimit cookie scopeRestrictive
DomainRestrict to specific domainExplicit

Cross-Origin Resource Sharing

ConfigurationRecommendation
Allowed originsSpecify exact origins (no wildcard in prod)
Allowed methodsLimit to required methods only
Allowed headersRestrict to necessary headers
Max-ageSet appropriate preflight cache duration

Cross-Site Request Forgery Protection

ControlDescription
Synchronizer tokensInclude CSRF token in forms
Double-submit cookiesAlternative token pattern
Header verificationCheck Origin and Referer headers
SameSite cookiesSet SameSite attribute

API Security

RESTful APIs require specific considerations:25

ControlDescription
Rate limitingPrevent abuse and DoS
AuthenticationOAuth 2.0 or OpenID Connect26
JWT validationVerify signature, issuer, audience, expiration
VersioningManage breaking changes
Status codesReturn appropriate HTTP status codes
URL securityAvoid 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:

LanguageTools
PythonBandit, Pylint security plugins
JavaScriptESLint security plugins, Semgrep
Gogosec, staticcheck
JavaSpotBugs, PMD, SonarQube
C/C++Clang Static Analyzer, Coverity
Rustcargo-audit, clippy

Dynamic Application Security Testing (DAST)

Test running applications for vulnerabilities:

ToolTypeDescription
OWASP ZAPOpen sourceComprehensive web app scanner
Burp SuiteCommercialProfessional penetration testing
NiktoOpen sourceWeb server scanner
sqlmapOpen sourceSQL injection detection

Software Composition Analysis (SCA)

Identify vulnerabilities in dependencies:


$ trivy fs --scanners vuln .
$ grype dir:.
$ npm audit
$ pip-audit

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 CategoryExamples
AuthenticationLogin success/failure, logout, MFA events
AuthorizationAccess denied, privilege escalation
Input validationRejected input, malformed requests
Application errorsExceptions, crashes, unexpected states
Administrative actionsConfiguration changes, user management
Data operationsAccess to sensitive data, modifications

Logging Best Practices

PracticeDescription
Structured formatUse JSON for machine parsing
TimestampsUTC with millisecond precision
ContextInclude sufficient detail without secrets
IntegrityAppend-only storage, consider signing
RetentionDefine retention periods per regulations

Sensitive Data to Exclude

Never log the following:

Data TypeReason
PasswordsAuthentication credentials
Session tokensSession hijacking risk
API keysUnauthorized access risk
Credit card numbersPCI-DSS compliance
Health informationHIPAA compliance
Cryptographic keysComplete 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.

SolutionUse Case
HashiCorp VaultEnterprise secrets management
AWS Secrets ManagerAWS-native applications
Azure Key VaultAzure-native applications
GCP Secret ManagerGCP-native applications
Kubernetes SecretsContainer orchestration (encrypt at rest)

Environment Variables

For containerized applications, inject secrets via environment variables or mounted files:


$ podman run -e DB_PASSWORD_FILE=/run/secrets/db_password \
-v ./secrets:/run/secrets:ro \
ghcr.io/armorred/nginx:latest

Rotation

PracticeDescription
Scheduled rotationRotate on defined schedule
Compromise responseImmediate rotation on suspected breach
Zero-downtimeImplement graceful rotation procedures
Audit trailsMaintain logs of rotation events

References


1

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

2

OWASP Cheat Sheet Series - OWASP. https://cheatsheetseries.owasp.org/

3

CIS Benchmarks - Center for Internet Security. https://www.cisecurity.org/cis-benchmarks

5

CIS Oracle Java Benchmark - Center for Internet Security. https://www.cisecurity.org/benchmark/java

7

Django Security Documentation - Django Software Foundation. https://docs.djangoproject.com/en/stable/topics/security/

8

Flask Security Considerations - Pallets Projects. https://flask.palletsprojects.com/en/stable/security/

10

CIS PostgreSQL Benchmark - Center for Internet Security. https://www.cisecurity.org/benchmark/postgresql

11

CIS MySQL Benchmark - Center for Internet Security. https://www.cisecurity.org/benchmark/mysql

12

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

13

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

14

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

15

Digital Identity Guidelines: Authentication and Lifecycle Management - NIST SP 800-63B. https://pages.nist.gov/800-63-3/sp800-63b.html

16

CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') - MITRE. https://cwe.mitre.org/data/definitions/89.html

17

CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - MITRE. https://cwe.mitre.org/data/definitions/79.html

18

CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - MITRE. https://cwe.mitre.org/data/definitions/78.html

19

CWE-20: Improper Input Validation - MITRE. https://cwe.mitre.org/data/definitions/20.html

23

CWE-116: Improper Encoding or Escaping of Output - MITRE. https://cwe.mitre.org/data/definitions/116.html

26

The OAuth 2.0 Authorization Framework - IETF RFC 6749. https://datatracker.ietf.org/doc/html/rfc6749

27

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

28

Guide to Computer Security Log Management - NIST SP 800-92. https://csrc.nist.gov/publications/detail/sp/800-92/final

29

The Twelve-Factor App - Adam Wiggins. https://12factor.net/config