Security by Framework

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.

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'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.

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.

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.

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.

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.

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.