misconfiguration
11 articles with this tag
DC Medicaid data exposure (about 400,000 people): Medicaid IDs left in published reports — what members and report publishers should do
The District of Columbia Department of Health Care Finance (DHCF), which runs DC Medicaid, said two statistical reports posted on its website from 2023 to July 2026 contained the underlying personal data in hidden fields that people without permission could access. The data included Medicaid ID numbers, dates of birth, provider names, race, gender, ward and ethnicity; DHCF says beneficiary names, Social Security numbers and financial account information were not included. DHCF learned of the issue on July 21, 2026 and removed the reports. Its report to the US Department of Health and Human Services (HHS) lists 399,086 people. Our conclusion: a report that shows only totals on screen can still carry the source data inside the file. Members should watch for medical services they never received; publishers should rebuild public files so that they never contain the source rows.
Cloud storage public exposure: when data can leak even with Block Public Access enabled
Bucket leaks come from configuration, not attack. The line that matters in the docs: block public access settings do not alter existing policies or ACLs — the public settings remain underneath the block, and removing the block restores public access. So the goal is not "blocking is enabled" but "nothing is public even with blocking off". Apply it at the account level, because a bucket policy can grant someone the ability to turn a bucket-level block off. And "public" is defined more broadly than people assume.
4 common security mistakes: default settings, forgotten services, missing monitoring and over-trusted input validation
Incidents come from a small set of recurring patterns, and the patterns are clearer sorted by belief than by technology. Four of them: defaults must be safe (nothing was configured), unused things must be harmless (nothing was closed), we would notice (nothing is observable), and validated input must be safe (too much was delegated to the input). None of these needs deep technical knowledge to fix — they need a habit of checking. Here is what to look at for each.
ASP.NET Core security — a production hardening reference
ASP.NET Core is a mature, stable framework, 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.
Django security — a production hardening reference
Django ships many 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.
Spring Boot security — a production hardening reference
Spring Boot is a stable framework, 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.
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 file. 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: trusted-proxy misconfiguration and defense
XFF is a client-forgeable header. An indiscriminate scanner puts injection probes in a spoofed XFF, and a 'trust all proxies (wildcard)' setting lets it through. Short-term fix: sanitize the IP header at the boundary. Root-cause fix: trust only the right proxies (or none). Zero impact still left a setting to fix.
A case where Laravel's .env was publicly readable: a shared-hosting placement mistake and how to fix it
The cause: the whole app sat under the web root; only public/ should be visible. Fix in three steps — a temporary .htaccess block, rotate keys, restructure — then prevent it with process.