Why this is in the vault
Part 3 of Technically's "Software Eng for Vibe Coders" series, teaching non-engineers the authentication-vs-authorization split and where vibe-coded apps actually leak data — worth keeping alongside Parts 1 and 2 as a plain-language artifact for the same audience.
The core argument
David Krevitt (a new byline for this series — Part 1 was Justin Gage) separates two problems vibe-coded apps conflate: authentication (proving who you are — handled well today by third-party providers like Clerk, social login, session tokens, sign-out-of-all-devices, and SSO/Okta/WorkOS for enterprise buyers) versus authorization (controlling what an authenticated user can actually touch — handled badly, and getting worse as an app scales). The piece walks role-based access control, row-level security (RLS) in Postgres, middleware for route protection, an "authorization planning matrix" mapping roles to features, and ownership-based access (a user should only see records scoped to their own org). The load-bearing line is "never trust the frontend" — authorization has to be enforced at the API and the database, not just hidden behind a UI that doesn't render a button. It cites a scan finding 170 of 1,645 vibe-coded apps with missing or unenforced row-level security, exposing data to anyone who guessed or scraped the right ID.
Mapping against Ray Data Co
This is a direct audit checklist for any RDCO-provisioned Postgres surface (MAC, Squarely backends, any client-facing app): does RLS actually exist on tables holding customer/user-scoped data, or does the app rely on the frontend simply not rendering other users' records? The "never trust the frontend" framing is the same failure mode as a coding agent silently accepting a database schema nobody reviewed (per the Aug 25 Databases + Storage note) — authorization is another decision that gets made implicitly by the agent's defaults unless someone deliberately checks it. Worth a five-minute pass on any surface where a coding agent set up auth: does an authorization planning matrix exist anywhere, even informally, or is role/access logic scattered across route handlers with no single source of truth?
Related
- [[2026-08-25-technically-vibe-coders-databases-storage]] — same series, Part 2, same sponsor
- [[2026-08-11-technically-frontend-backend-vibe-coders]] — same series, Part 1, same sponsor
- [[feedback_no_secrets_on_disk]]
⚠️ Sponsorship
Railway sponsors this issue — the third confirmed recurrence for this specific "Software Eng for Vibe Coders" series (Part 1, Aug 11; Part 2, Aug 25; now Part 3). This resolves the open question the README flagged on 2026-08-11: Railway is not a one-off — it is the fixed sponsor for this entire 6-part series, distinct from the unrelated "What's going on with open-weight models?" issue (Aug 18, no sponsor) which is a different Technically series/author (Will Raphaelson) and should not be read as evidence against series-level recurrence. Treat Railway-as-series-sponsor as established; the earlier "watch whether it recurs" framing can close.
Source fidelity note: Gmail delivered this message with an empty plaintext and HTML body (both plaintextBody and htmlBody were blank on get_thread fetch, confirmed on a re-check). Content reconstructed via WebFetch of the canonical published URL, located via WebFetch of the Technically archive page after WebSearch failed to index the post (published same-day).