access control
11 articles with this tag
File upload vulnerabilities — preventing web shells and RCE by design
The core of an upload hole isn't 'receiving a file' — it's where you put it and whether it can execute. Unauthenticated endpoint + no type validation + stored under the web root + scripts run there = web shell → RCE. Defend in layers: (1) auth/permission + CSRF on the endpoint, (2) server-side allow-list + content inspection, (3) store outside the web root (or disable execution), (4) randomize names, never trust user paths. Not one wall — a stop at every step.
What is PCI DSS — the security standard for handling credit-card data
PCI DSS (Payment Card Industry Data Security Standard) is the international standard for businesses that store, process, or transmit card data. Set by the card brands, it requires network protection, encryption of stored data, least-privilege access control, monitoring/logging, and vulnerability management. In practice the safest move is to not hold card numbers yourself — hand processing to a compliant payment provider (tokenization) and shrink your scope.
What is the OWASP Top 10 — the standard list of the 10 biggest web-app risks
The OWASP Top 10 is a list the non-profit OWASP publishes every few years of the 'most critical web-app risks.' It's a common language for developers and operators. The current edition (2021) is led by Broken Access Control, followed by injection, misconfiguration, vulnerable and outdated components, authentication failures, and more. These are risk CATEGORIES, not individual exploits — use them as a lens to audit your own app.
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.
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.
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.
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.
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.
Added a login and called it secure? — authentication vs authorization
Authentication = verifying who someone is; authorization = deciding what they may do. They're different, and adding a login is not authorization. Without owner (user_id) scoping on data, 'logged in = sees all data' — the top-ranked OWASP Broken Access Control. Add an open registration scaffold and a stranger can sign up and walk in. Defenses: scope every query to the owner, close unneeded registration, defense-in-depth, audit/access logs before an incident, detect new sign-ups.
What is IDOR — seeing someone else's data just by changing an ID
IDOR lets a user change ?id=124 to 125 and read someone else's invoice or personal data — broken access control. The real defense: server-side, check on every access whether the logged-in user is allowed this object. Hard-to-guess IDs are not a fix.