Skip to content

Security: maherDEV-IE/ScopCall

Security

security.md

Next.js Security Reference

Last Updated: 07/02/2026 Purpose: Security reference for Next.js applications based on observed attack patterns and implemented defenses.

Observed Attack Patterns

1. Command Injection Attempts

  • Base64-encoded shell scripts
  • Malware downloads from suspicious IPs: 94.154.35.154, 193.142.147.209, 91.200.220.168, 5.181.2.123
  • Mitigation: Input validation, Server Actions with zod schemas

2. Malware Installation Attempts

  • Cryptocurrency miners (xmrig, c3pool)
  • Botnet binaries (yamaha.x86_64, cARM, cX86)
  • System persistence (cron jobs, systemd services)
  • Mitigation: Container hardening, read-only filesystem

3. Reverse Shell Attempts

  • Netcat reverse shells to 193.142.147.209:12323
  • Persistent backdoor attempts
  • Mitigation: Network policies, container isolation

4. Code Injection Attempts

  • ReferenceError: returnNaN is not defined
  • Permission denied errors (/dev/lrt, //lrt)
  • Mitigation: Strict CSP, input sanitization

Implemented Security Measures

✅ Container & Infrastructure Security

Docker Configuration:

  • Non-root user: 1001:1001 (nextjs:nodejs)
  • Read-only filesystem: read_only: true
  • Capability dropping: cap_drop: ALL
  • No new privileges: no-new-privileges:true
  • Resource limits: Memory (256M), CPU (0.25)
  • Temporary filesystem: /app/.next/cache with noexec,nosuid
  • Node security: --no-warnings --disable-proto=delete
  • Telemetry disabled

Dockerfile:

  • Multi-stage build (deps, builder, runner)
  • Minimal Alpine-based production image
  • Standalone output for reduced attack surface
  • Proper file ownership (nextjs:nodejs)

✅ Server Actions Security

Encryption Key:

  • NEXT_SERVER_ACTIONS_ENCRYPTION_KEY configured
  • Passed as build arg and environment variable
  • AES-GCM encrypted for consistent encryption across deployments
  • Prevents sensitive data exposure in closures

Input Validation:

  • All forms use Server Actions with zod validation
  • Schema-based validation for all user inputs
  • Type-safe form handling with error messages
  • Server-side validation prevents injection attacks

✅ Content Security Policy (CSP)

Strict CSP with Nonces:

  • Implemented in middleware with cryptographically secure nonces
  • Nonce generated per request using crypto.randomUUID()
  • Removed unsafe-inline and unsafe-eval from script-src (production)
  • Removed unsafe-inline from style-src (production)
  • 'strict-dynamic' enabled for script loading
  • Development mode allows unsafe-eval for debugging
  • Next.js automatically applies nonces to Script components

CSP Directives:

default-src 'self'
script-src 'self' 'nonce-{nonce}' 'strict-dynamic'
style-src 'self' 'nonce-{nonce}'
img-src 'self' blob: data: https:
font-src 'self' data:
connect-src 'self'
object-src 'none'
base-uri 'self'
form-action 'self'
frame-ancestors 'none'
upgrade-insecure-requests

Implementation:

  • Nonce generated in middleware per request
  • CSP header set in middleware (not in next.config.mjs)
  • Nonce passed via x-nonce header for reference
  • Middleware matcher excludes prefetches and static assets

✅ HTTP Security Headers

  • X-Frame-Options: DENY - Prevents clickjacking
  • X-Content-Type-Options: nosniff - Prevents MIME sniffing
  • Referrer-Policy: origin-when-cross-origin - Limits referrer leakage
  • X-XSS-Protection: 1; mode=block - XSS protection
  • Permissions-Policy: geolocation=() - Restricts browser APIs

✅ Middleware Security

  • Secure cookies: secure: true, httpOnly: true
  • Path filtering for static files and API routes
  • Locale detection and routing

✅ Form Security

Server Actions Implementation:

  • All forms use Server Actions ('use server')
  • Zod validation schemas for all inputs
  • Type-safe error handling with useActionState
  • Client-side and server-side validation
  • Input sanitization (regex patterns, length limits)
  • Email normalization (lowercase, trim)

Validation Features:

  • Required field validation
  • Email format validation
  • Phone number format validation
  • Character whitelisting (names, company)
  • Length limits on all fields
  • Enum validation for select fields

Security Checklist

  • Container hardening (non-root, read-only, capabilities)
  • Server Actions encryption key
  • Strict CSP (no unsafe-inline/unsafe-eval)
  • HTTP security headers
  • Secure cookies in middleware
  • Form validation with zod
  • Server Actions for all forms
  • Input sanitization

Best Practices

Server Actions

  • Always validate input with zod schemas
  • Never trust client input
  • Use encryption keys for closures with sensitive data
  • Return clear error messages for validation failures

Input Validation

  • Validate all user inputs (params, searchParams, form data)
  • Use parameterized queries for database access
  • Sanitize user-generated content
  • Never execute commands with user input

CSP

  • Avoid unsafe-inline and unsafe-eval
  • Use 'self' for same-origin resources
  • Regularly review and tighten CSP policies

Container Security

  • Always run as non-root user
  • Use read-only filesystem when possible
  • Drop all unnecessary capabilities
  • Set resource limits

References

There aren’t any published security advisories