Press F12
and it is all visible

“Done in 5 minutes? It worked when I followed the tutorial?”

Try it. With no sales, you may never notice, close the business and bury it.
When sales grow and you become a target — that is when you find out.

Why is it scary? Two familiar examples

• iOS in-app purchases — the field that used to torment game companies. Apple’s 30% fee, auto-renewals, refunds, receipt verification…
• Small-business customer support — payment incidents draw customer fury directly. “Where is my money?” Abuse, a flood of 1-star reviews, reputation destroyed in a month.

What the Network tab shows

API endpoints, request contents, response contents
Which AI model is used, environment variables, localStorage, cookies
All publicly visible.

The bedroom-drawer analogy

Taking your diary out in your own room is not an incident.
The real incident is letting a thief break the window and steal it.

The “thief” is an XSS attacker

Someone has planted malicious JavaScript on the page (Cross-Site Scripting).
JavaScript on the same domain can read all of localStorage → the malicious script steals the token.
HttpOnly cookies are invisible to JavaScript → it cannot steal them. HttpOnly’s job: prevent token theft even when XSS occurs.

The problem: all 4 basic defenses were missing

A B2B lead SaaS whose founder boasted, “I did not write a single line.”
API keys exposed in the frontend, no authentication, an unprotected database, no rate limiting.

Attack path

Browser console bypassed payment → paid features used for free → API quota exhausted.
Tried fixing it with Cursor → “It kept breaking other things” → gave up and shut down.

How it happened: two mistakes combined

An AI-agent social platform whose founder, Matt Schlicht, declared, “I did not write a single line.”
Built on Supabase: RLS off + a privileged key exposed in client JavaScript.
→ The anon key itself can be public. The incident came from combining disabled RLS with an exposed secret key.

First leak (July 2025)

A women-only app collecting driver’s licenses and selfies at signup.
Firebase Storage permissions were left open to everyone.
72,000 images leaked, including about 13,000 selfies and driver’s-license images.

Second leak (days later)

Another 1.1 million private messages leaked.
Including extremely sensitive conversations about abortion and affairs.

Case ① · Opening segment — the documentary’s protagonist

Security-startup CEO · Lives in Bali · Works 30 minutes a day · Only approves agent results

Four things we can only guess about how that person got there:

(For reference, some companies pay over 20 million won a month for Palantir Enterprise.)

Case ② · Minutes 28–32

A hotel-booking agent was told to “spend only 500,000 won” and spent 760,000 won.

A controlled attack experiment by KAIST researchers and KBS staff. The scenario uses hostile code and prompts planted on an external web page to misdirect the agent. Not an actual victim.

My background: magazine reporter (introduced on day one). How media works is the result of editorial intent.

Watch at home and check two things:
① The CEO’s effort, study, trial and error, and costs — are they shown?
② The attack mechanism (attention, tool calling, judgment, IDPI) — is it clearly explained?

If not, it was cut in editing. That is the nature of media.

Analogy

On the ground floor are mailboxes for 100 apartments.
“Only I can open my own mailbox” — that is normal.
→ RLS enabled = normal

What if you do not enable it?

Any resident can open all 100 mailboxes.
They can read neighbors’ bank statements, card bills and registered mail.
→ Supabase/Firebase default: OFF. Without enabling it, anyone can read and modify every user’s data.

Analogy (secret keys only)

A hotel employee’s master key opens every room.
OpenAI, Anthropic and AWS secret keys work the same way. “With this key, you can use that company’s services however you like.”
→ Usage is billed to the key owner: you. Public keys are different; see slide S10.

What if you put it in the code?

It is like hanging the hotel master key unlocked at the front entrance.
Anyone passing by can take it, open every room and empty the minibars and safes.
→ Once a key reaches GitHub, bots collect it within 30 minutes → OpenAI bills explode, reaching tens to hundreds of millions of won in a month.

Public keys can use the prefix

Public keys such as Firebase apiKey, Stripe pk_* and Supabase anon can use NEXT_PUBLIC_* or VITE_*. They are intended to be public.
→ Never use these prefixes for secret keys. See S10.

Analogy

A shop has two kinds of writing.
The sign: any passerby can read it (phone, address, menu).
Inside the owner’s safe: even staff cannot see it (cash, seals, bankbooks).
→ A key prefixed with NEXT_PUBLIC_ is writing on the sign. The build sends it straight to the browser.

What if you add it to a secret key by mistake?

Like writing the safe’s combination on the shop sign.
Add NEXT_PUBLIC_ to a secret key, such as OpenAI sk-* or Supabase service_role, and one F12 press puts it in a thief’s hands.
→ VITE_ and REACT_APP_ work the same way: the same trap in other frameworks.

A common confusion: “But Firebase says to put the key in Info.plist?”

Correct. Firebase apiKey is a public key with no privileges by itself, so it can be embedded in the app.
The real defenses are Firebase Security Rules and App Check. Google Maps keys, Stripe `pk_*` and Supabase `anon` are similar.

→ Recall the public vs. secret key table in S10. Secrets stay in the backend; public keys can go in apps, but policies must be enabled.

Analogy: a restaurant

Customer = user (browser)
Employee = your server (BFF, Backend For Frontend)
Owner = external API (OpenAI, bank, payments)
→ Customers must not enter the owner’s office and touch the safe. The employee takes their request to the owner.

What if the customer meets the owner directly?

The customer learns the safe’s combination (API key).
Then they return daily pretending to be another customer and empty the safe.
→ Calling OpenAI/banks directly from the client exposes API keys. Bots collect them and bills explode.

What is a source map?

Your code (TS, JSX, modern JS) → the build tool runs a four-stage conversion, including compression, translation and bundling → sends it to the browser. People cannot read the transformed code.

For debugging, the build separately creates an original-to-compressed-code translation table. That is the .map file: the source map.

Analogy: a translation table for the English edition of a Korean book, used to locate the Korean original when the English edition has a typo.

Cases where source maps are public

Check whether your project exposes original code, comments or core logic.

Choose between two options

① Disable completely (`sourcemap: false`): safest, but production errors become harder to trace.
② hidden-source-map: generate maps without adding a sourceMappingURL comment. Ordinary users do not see them in F12.

How hidden-source-map works

Do not include generated .map files in the server deployment; upload them separately to an error-tracking service such as Sentry or Datadog.
→ Production errors can be traced to the original line in Sentry, but not viewed through F12.

Options by framework

Next.js — productionBrowserSourceMaps: false + Sentry integration
Vite — build.sourcemap: 'hidden'
Webpack — devtool: 'hidden-source-map'
CRA — GENERATE_SOURCEMAP=false (CRA does not support hidden maps)

Analogy

Looking only at a finished building, ordinary people cannot locate vents, secret passages or safes.
A blueprint shows where everything is.
→ A source map pairs compressed code with original code. With it, F12 shows the original as-is.

What if you publish the blueprint?

The thief learns every vent, secret passage and safe location.
The exterior is unchanged, but the ways in become countless.
→ Exposed production .map files reveal business logic, security checks and comments. Weak points are immediately visible.

Analogy

Git = automatic diary backup (photographing and saving it to the cloud daily)
.env = secret diary (passwords, bank codes, gossip about someone)
.gitignore = the “do not back this up” list
→ Git automatically uploads all files to the cloud. Put the secret diary in .gitignore to keep it out.

What if it is not in .gitignore?

Even the secret diary gets backed up to the cloud. And it stays in history forever. Once a password is uploaded, replace the key immediately.
→ An accidental .env commit to GitHub lets bots harvest keys within 30 minutes. AWS/OpenAI bills explode. Deleting it afterward does not remove it from history.

My actual experience

I told Claude, “Write this down.”
It replied, “Yes, I recorded it.”
I asked in the next session: it did not know. Quite often, it never recorded anything.

An even worse case

Sometimes, even within the same session, it cannot remember what you said 2 hours ago.
→ As context grows, earlier content becomes blurry. Exactly the Context Rot from session 3.

account.md (add to .gitignore)

Where keys were issued, cloud-account emails, infrastructure settings, container names
Never include passwords

When rules grow, move them to a separate file

When security rules get long, move them to SECURITY.md and leave only a reference in CLAUDE.md.
→ The canonical-source/reference pattern from session 3: keep CLAUDE.md short and separate details by file.

This is not the end

Web and backend systems have an enormous number of things to defend against.
These 6 are a starting point. OWASP Top 10, token storage, CSP, CORS, rate limits, SQL injection, CSRF, SSRF, race conditions — the list goes on.
→ Today’s 6 are the ones vibe coders most often miss.

① Authentication token: stored in localStorage

Key *_token, JWT format, 120 characters.
→ A core anti-pattern from session 4. Anyone can see the token with one F12 press.

② Decoded token: long-lived, 24 hours

HS256; only sub and exp in the payload (no iat, jti, iss or aud); expires in +24 hours.
→ Standard access tokens last 15 minutes to 1 hour. 24 hours without jti means no forced revocation after theft and unrestricted use for 24 hours.

③ Security response headers: 5 missing

CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy: all missing.
→ Only HSTS is enabled. A CSP line could have blocked inline XSS scripts — zero layers of defense.

④ Many third parties + no CSP = more supply-chain attack surface

Loads GTM, GA and multiple external CDNs. No CSP → if one domain is compromised, malicious code can reach all users of the site.

① Using localStorage for tokens alone: open to debate

Review token storage together with CSP and XSS defenses.

② Combination (localStorage + no CSP + 24h + no jti) — items to check together

Check CSP, token expiry and protections against token reuse together.

③ In one line

Never put sensitive values (authentication, payments, personal identifiers) in localStorage.
Dark mode, language and UI state are fine. Secrets are not.

④ This service

Closer to the latter combination (②).
The criticism is not about localStorage alone: the combination makes it dangerous.

First: not unable, just undone

They built a clean service with Vite, React and Vercel. They are clearly smart.
They skipped one 5-minute task: putting authentication tokens in HttpOnly cookies.

Second: even trillion-won companies skip it

EnrichLead, Moltbook, Tea — all were taking payments.
They skipped the minimum, and one incident shut a company down in a week (EnrichLead).

Third: you face the same threats

The moment you add payments and accept users through vibe coding, one F12 press shows everything.

One last thing

My entire instruction was “Run a security audit” in Korean.
Claude found this much from that one line.

So what if someone skilled at attacks targeted the same site? What then?

That was said 27 years ago.

Back to session 1: “Books matter / do not dismiss experts / Anthropic learned from books too.”
This man is an example. A god of the software industry.

Of course there are also Dijkstra of Dijkstra’s algorithm and Liskov of the Liskov substitution principle.
More precisely, he is a god of enterprise practice, not theory.
Different fields, but yes: a god you could not catch even after learning to code for a thousand years.

2023–2025 — still active

martinfowler.com · Runs the Exploring Generative AI series.
The author of a book from 27 years ago still writes about coding in the AI age.

In other words, your Claude has probably learned from all of his writing too.

Simpler than code. Anyone can try.

Try image-generation AI for illustrations, landscapes, oils and watercolors.

My example: refined 100+ images since the Gemini app first launched. Made the emblem for my motorcycle group myself.