Secure Your App: Fundamentals of App Security for Vibe Coding

Technological concepts & security guidance (core of the video)

• AI app speed vs. security risk: Building with AI can move quickly, but security vulnerabilities are easy to miss if you don’t apply fundamentals.
• Platform-agnostic approach: The guidance applies regardless of which “vibe coding”/editor stack you use.

---

1) API key types: what to expose vs. hide

Different providers use different “named” keys, but the underlying idea is consistent:

• Some keys are designed to be public
• Others must be kept secret

General rule for dashboards

• Public keys are typically shown by default in the provider dashboard.
• Secret keys are typically hidden by default and only revealed via a “reveal/show” button.

Examples given

• Supabase
  • Anonymous key: displayed by default → intended for public/client usage.
  • Service role key: hidden behind reveal → must be protected.
• Stripe
  • Publishable key: shown by default → safe to expose.
  • Secret key: revealed only → must be hidden.
• OpenAI
  • The key is only fully shown at creation time; afterwards only partial characters are visible → treat as secret.

What keys are actually allowed to do (threat model)

Secret keys grant powerful access

• With another customer’s OpenAI key, someone could consume billed API capabilities for that customer.
• With Stripe secret key, someone could potentially withdraw funds / act on behalf of the account.
• With Supabase service role key, someone could broadly read/delete/create and bypass intended app restrictions.

Public keys are constrained

• Publishable key / anonymous key mainly acts as a reference pointer to route requests to the correct project/app.
• Their real power is limited by row-level/role security policies (covered later).

---

2) Preventing key leakage: backend-only + no hardcoding

Keep secret keys on the backend

• Frontend code runs on user devices and can be inspected (keys could be extracted).
• Backend code runs on your server and isn’t directly accessible to users.

Use backend mechanisms to call third parties

• Use Supabase Edge Functions to call third-party APIs securely.

Do not hardcode API keys into source code

• Avoid embedding keys directly in Edge Function code.
• Use a secret manager / environment variable approach inside the backend.

Ask AI to use environment variables rather than hardcoding

• Validate keys don’t appear in the repository (e.g., search the editor/repo for the key).
• If keys are committed to GitHub, they may be exposed depending on settings/history.

---

3) Supabase database security: Row Level Security (“rollable/role security”)

The video describes securing the Supabase database using row-level security policies (RLS).

Step 1: Ensure row-level security is enabled

• Tables with security disabled (indicated by a red lock icon) are vulnerable.
• If RLS is disabled, “any users can access this table any way they want” → unacceptable.
• AI tools may enable it automatically, but you should verify in the dashboard.

Step 2: Define RLS policies (by action)

There are four policy types:

• SELECT
• INSERT
• UPDATE
• DELETE

If a particular action has no policy, then that action is not permitted for users.

Common policy patterns described

• true policy
  • Allows access broadly (often only appropriate for safe cases like public SELECT).
• User-scoped policies using IDs
  • Pattern: allow access only when a row’s owner field matches the authenticated user ID (e.g., profile_id = auth.uid()-style logic).
  • Prevents users from modifying other users’ data.

Example insight: chat apps require more complex policies

For chat messaging:

• INSERT may be restricted to the message author (sender).
• SELECT must restrict messages to members of the conversation (1:1 vs group chat).
• A simple true policy would leak data; more complex logic is needed.

---

4) Security Advisor: good but not complete

• Supabase includes a Security Advisor that flags common misconfigurations.
• Example detected issue:
  • A policy exists, but RLS is disabled on that table → the Security Advisor raises an error.

Limitation emphasized

• It may not detect subtler logic flaws.
• Example failure mode:
  • An INSERT policy contains true, effectively allowing anyone to insert any data (enabling impersonation scenarios).

---

5) Automated testing to validate RLS behavior

The video proposes automated tests to catch edge cases beyond what the Security Advisor finds.

Test setup (tooling and workflow)

• Use an AI-assisted coding editor/workflow (Cursor) to:
  • Generate unit tests automatically.
  • Set up a testing framework (mentions Vitest).
• Demonstrates pass/fail with a trivial example test (e.g., 1 + 1 === 2).

Use a local Supabase instance (avoid production risk)

• Do not test against production.
• Start local Supabase (the video references using mpx / npx-like commands and local URLs).
• Locally running service keys may be “exposed,” but only the developer machine can access them.

Reset DB state every test run

To keep tests deterministic:

• Reset local Supabase database before each run:
  • Delete rows from tables
  • Delete users
• Use a service role/admin client for cleanup in test context.
• The video describes a reset function that:
  • Deletes table data
  • Deletes auth users
• Then applies schema/migrations (e.g., via schema.sql and Supabase migrations).

---

6) Concrete RLS test example: preventing profile tampering

The presenter builds an automated test verifying that User 2 cannot update User 1’s profile.

Test scenario (plain-language intent)

1. Create User 1.
2. Update User 1’s profile and verify the update succeeded.
3. Sign out.
4. Create User 2.
5. Attempt to update User 1’s profile using User 2’s session.
6. Verify User 1’s profile data was not changed (“nothing is hacked”).

Notes about a subtlety in test logic

• When an RLS policy blocks an UPDATE, it may fail silently:
  • No error is thrown
  • The update simply does not occur
• Therefore, the test should verify data integrity (values remain unchanged) rather than relying only on error presence.

Result

• The test passes, demonstrating RLS policies work “as intended.”
• The approach is presented as expandable to richer use cases like chat authorization (multi-user message visibility and insertion restrictions).

---

Main speakers / sources (from the subtitle content)

• Primary speaker: The presenter/host narrating the tutorial (no specific name given in subtitles).
• Product/documentation sources referenced:
  • Supabase (dashboard, Edge Functions, RLS policies, Security Advisor)
  • Stripe and OpenAI API key behavior examples