framework
9 articles with this tag
Django security — a production hardening reference
Django is 'batteries included' with safe defaults (ORM, CSRF, auto-escaping, auth), but incidents come from settings. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — DEBUG=False + ALLOWED_HOSTS, externalizing SECRET_KEY, pip dependency CVEs, production security settings (SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE, etc.), authorization (owner scope), injection and output (raw/extra, mark_safe), CSRF/sessions/admin, SSRF/uploads, and (3) a self-verification checklist. Defensive only — no attack steps.
Security by framework — defenses specific to the stack you use
Whatever framework you use, the *types* of weakness attackers hit are largely the same (access control, secrets, injection, dependency CVEs, misconfiguration). What differs is each framework's 'dangerous defaults' and 'the spot most often targeted.' This site provides, per framework, the default pitfalls and the hardening steps. Start with the chapter for the stack you actually use.
Laravel security — a production hardening reference
Laravel's defaults are strong; production incidents come from config and operations. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) a table of dangerous defaults, (3) per-area guidance — secrets/APP_KEY, production config (APP_DEBUG/caching), authorization (Policy/Gate, Mass Assignment), injection/output (Eloquent binding, Blade), sessions/CSRF/cookies, uploads, HTTPS/headers/rate limiting, Composer dependency CVEs, and (4) a self-verification checklist. Defensive only — no attack steps.
Next.js security — a production hardening reference
Next.js's defaults are fairly safe, but incidents happen at the server/client boundary. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — the boundary and env vars (NEXT_PUBLIC_), dependency CVEs (including core RCE), Server Actions / Route Handlers authorization + input validation, SSRF on server-side fetches, security headers/CSP, auth/session/cookies, rate limiting, and (3) a self-verification checklist. Defensive only — no attack steps.
Spring Boot security — a production hardening reference
Spring Boot is a solid foundation, but incidents come from dependencies, config, and authorization. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — dependency CVEs (Log4Shell-class, judge by running version), production config and externalized secrets, Spring Security authorization (default-deny/method security/owner checks), Actuator/management exposure reduction, unsafe deserialization, injection, headers/CSRF/session, SSRF, and (3) a self-verification checklist. Defensive only — no attack steps.
WordPress security — a production hardening reference
WordPress has the largest share, so it's the biggest target — but the entry points are predictable (plugin/theme vulnerabilities, skipped updates, weak admins, exposed admin panels). This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — automatic updates, minimizing plugins/themes, strong admin + 2FA, reducing admin exposure (xmlrpc/REST enumeration/file editing), wp-config and secrets, file permissions, HTTPS/backups, PHP/dependency freshness, and (3) a self-verification checklist. Defensive only — no attack steps.
ASP.NET Core security — a production hardening reference
ASP.NET Core is a mature, solid foundation, but incidents come from settings. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — don't expose detailed errors / the Developer Exception Page in production, externalize secrets (User Secrets/env/Key Vault), NuGet dependency CVEs, authorization ([Authorize], fallback default-deny, resource-based/owner), over-posting (DTOs/[Bind]), unsafe deserialization (avoid BinaryFormatter), HTTPS/headers/antiforgery, SSRF, and (3) a self-verification checklist. Defensive only — no attack steps.
Express (Node.js) security — a production hardening reference
Express is minimalist — it guards almost nothing by default, so you add the defenses. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — security headers (helmet) + disabling x-powered-by, npm dependency CVEs, input validation and injection (SQL/NoSQL operator), authentication and owner-scoped authorization, rate limiting and size caps, sessions/cookies/CSRF, SSRF, production error handling (no stack exposure), NODE_ENV, and (3) a self-verification checklist. Defensive only — no attack steps.
Ruby on Rails security — a production hardening reference
Rails ships conventions and safe defaults (CSRF protection, Strong Parameters, an ORM), but production incidents come from operations. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — secrets and credentials (master key/secret_key_base), production config (force_ssl, no exception exposure), gem CVEs, Strong Parameters/Mass Assignment, authorization (Pundit, owner scope), injection and dangerous methods (where interpolation/send/constantize), sessions/cookies/CSRF, SSRF/uploads, and (3) a self-verification checklist. Defensive only — no attack steps.