misconfiguration
8 articles with this tag
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.
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.
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.
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.
Did you leave a secret file in a public directory? Audit your webroot
Anything in your webroot is fetchable by URL by anyone. A leftover token/credential JSON, .env, or backup means instant exposure — and if it came from a shared template, every site has the same hole. Fix: put only publicly-shareable things in the public dir, keep secrets outside the webroot at perms 600, and once you find one, audit every site and host.
What is X-Forwarded-For (XFF) spoofing — the trusted-proxy config trap
XFF is a client-forgeable header. A blind scanner hides injection probes in a spoofed XFF; 'trust all proxies (wildcard)' lets it through. Patch = sanitize the IP header at the boundary; root fix = trust the right proxies (or none). Zero impact still left a setting to fix.
Laravel apps' .env was readable by the whole world — the most common shared-hosting mistake
The cause: the whole app sat under the web root; only public/ should be visible. Fix in three steps — .htaccess first aid, rotate keys, restructure — then prevent it with process.