"Laravel security," "WordPress hardening" — when we search, we look for answers per technology. This page is the entry point to per-framework defense (no attack steps).
Shared (same on every framework)
access control, secrets, injection, dependency CVEs, misconfiguration. The basic defenses are shared too.
Framework-specific (each chapter)
the "dangerous defaults" and "the spot most often targeted." This is the only part that differs by technology.
Weakness types shared by every framework
The big picture first. These types are targeted over and over regardless of technology; each framework chapter explains how they show up in that technology.
Guides by framework
Read the chapter for your stack. Each goes "default dangers → most-targeted spot → hardening steps."
WordPress
Laravel
Next.js
Java / Spring
Other frameworks
Settings to check first in production (quick table by framework)
On every framework, check two things first: whether production shows detailed errors, and where your secrets live. The setting names differ, so find your row below. Names were checked against each project's current official docs (version in the last column).
| Framework | Turn off detailed error pages | Where secrets live, and the catch | Often-missed setting | Docs checked |
|---|---|---|---|---|
| WordPress | WP_DEBUG set to false in wp-config.php (false by default) | DB credentials in wp-config.php; never leave copies in public directories | DISALLOW_FILE_EDIT to block file editing from the dashboard; delete unused plugins | Advanced Administration Handbook |
| Laravel | APP_DEBUG=false in .env | Never commit .env (an encrypted .env.encrypted is fine) | After config:cache, env() outside config files returns nothing | 13.x |
| Next.js | Run next build then next start; never expose the dev server | NEXT_PUBLIC_ variables are inlined into browser JavaScript | A secret given a NEXT_PUBLIC_ prefix | 16.x |
| Spring Boot | Keep stack traces out of error responses (leave the default) | Pass values via environment variables, not hard-coded config | Actuator exposes only health over HTTP by default; never set management.endpoints.web.exposure.include=* | 4.1 |
| Django | DEBUG = False | Load SECRET_KEY from an environment variable or file; keep it out of source control | Set ALLOWED_HOSTS; run manage.py check --deploy | 6.1 |
| Ruby on Rails | Use the production environment config (config/environments/production.rb) | config/credentials.yml.enc plus config/master.key; never commit master.key | config.force_ssl = true to enforce HTTPS | 8.1 |
| Express | NODE_ENV=production removes stack traces from the default error response | Pass via environment variables, not code | helmet for safe headers; app.disable('x-powered-by') | Current official guide |
| ASP.NET Core | The Developer Exception Page is on only in the Development environment (current template default) | User secrets are for development; use environment variables or a key vault in production | Never run production with ASPNETCORE_ENVIRONMENT set to Development | 10.0 |
Real cases: most incidents came from skipped updates and production settings, not core bugs
The pattern that stands out is not the framework flaw itself, but a fix that was available and not applied, or a development setting left in production.
- Equifax (2017): the fix for the Apache Struts flaw (CVE-2017-5638) was released the day it was disclosed, but it was not applied to a public system, and personal data on about 147 million people leaked (→ the Equifax breach).
- Log4Shell (2021): a flaw in a Java logging library. Many organizations had it pulled in through other components and could not tell whether they used it (→ Log4Shell).
- AI-agent cases (2026): when research AI agents reached real websites, credentials were read from an exposed debug page, and the sites did not notice (→ AI agents reaching real websites).
In the OWASP Top 10 (2025), number one is broken access control, number two is security misconfiguration, and number three is software supply chain failures (problems in the components you depend on). All of them happen on any framework.
How to check your own site
Only run these checks on sites you manage.
Open a non-existent URL and look at the error page
Use the framework's own check commands
python manage.py check --deploy; Laravel shows debug mode with php artisan about --only=environment. On Spring Boot, check management.endpoints.web.exposure.include in your config.Scan dependencies and what is visible from outside
npm audit for npm, composer audit for Composer, or osv-scanner for everything (from the browser: the dependency vulnerability scanner). For what outsiders can see, the security headers check shows missing headers, and the full site security audit checks .env and .git exposure, certificates, and cookie flags in one pass.Common mistakes and fixes
| Common mistake | What happens | Fix |
|---|---|---|
Giving a secret API key a NEXT_PUBLIC_ prefix | The key is inlined into browser JavaScript where anyone can read it | Drop the prefix, use it server-side only, and revoke the leaked key at the issuer |
| Exposing every monitoring endpoint (e.g. Spring Boot Actuator) | Configuration values and memory contents can be read from outside | Expose only health and similar; keep the rest behind authentication |
| Deactivating unused plugins but leaving them installed | The files stay on the server and stop receiving updates | Delete what you do not use |
| Reading an update notice without confirming it was applied | The hole stays open even though a fix exists (the Equifax pattern) | Check the version after updating and run dependency scans on a schedule |
This site's view: incidents come from how a framework is run, not the framework itself
Arguing "this framework is safe/dangerous" rarely helps. Most real incidents come not from a core bug but from usage — skipped updates, exposed secrets, missing authorization, dangerous defaults. This site runs on Next.js itself, and our main defense is nothing special: monitor dependency CVEs, keep secrets out of code and public directories, strong authentication, recoverable backups. Each framework chapter applies those basics to that specific technology.
First, cover the shared basics
Before diving into a framework chapter, it's efficient to first set up what works on every technology.
- Start: the security baseline checklist (admin accounts, secrets, patching, detection, recovery)
- Practice: the vulnerability-response playbook · monitoring dependency CVEs (osv-scanner)
- Secrets: keep secrets out of public directories
Sources
- WordPress Advanced Administration Handbook, "Hardening WordPress" and "Debugging in WordPress" — developer.wordpress.org
- Laravel 13.x, "Configuration" (Environment File Security / Debug Mode) — laravel.com
- Next.js, "How to use environment variables in Next.js" (16.x) — nextjs.org
- Spring Boot 4.1, "Endpoints" (Actuator exposure) — docs.spring.io
- Django 6.1, "Deployment checklist" — docs.djangoproject.com
- Ruby on Rails Guides, "Securing Rails Applications" (8.1) — guides.rubyonrails.org
- Express, "Production Best Practices: Security" and "Error Handling" — expressjs.com
- Microsoft Learn, "Handle errors in ASP.NET Core" (10.0) — learn.microsoft.com
- OWASP Top 10:2025 — top10.owasp.org
Read next
- Guides: WordPress security · Laravel security
- Basics: the security baseline checklist (shared by every framework)
- Glossary: what a CVE is (the unit for tracking a framework's known flaws)