Vibe Coding for Beginners: From Zero to App/Iterate the website
Lesson 3 / 3 · 40 min · 0 / 2 exercises
Course contents
Project · 2 hands-on exercises

Secure your site

Run a security review of your own site, fix what it finds, test it the way a stranger would, and write the rules down so the agent follows them from now on.

Time to apply the five habits to your own project. You'll ask the agent for a security review with a specific checklist, fix what it finds one item at a time, then test the live site the way a curious stranger would. Finally, you'll write the rules into the project so every future session starts with them.

Five questions about your site

  1. What data does it hold? Public menu data only, or names, emails and orders?
  2. Who can see or change it? Everyone, signed-in users, or only the owner?
  3. What secrets does it use? Any API keys, database keys or passwords, and where do they live?
  4. What code didn't you write? Packages, scripts from other sites, embedded widgets?
  5. What can the agent reach? Your files, your GitHub account, your hosting dashboard, live data?

For the Crumb & Co. site so far, the answers are short: public data only, no sign-in, no secrets, maybe one outside script. That's the safest place to be, and it's on purpose. The most secure sign-in is the one you don't need: the owner updates specials by editing a file, so there's no admin page to attack. If your project has a database or sign-in, which is common on the builder track, your answers are longer, and so is your review.

The security review prompt

Paste this into your agent
Do a security review of this whole project. Don't change anything yet. Check for:
1. Secrets or keys anywhere in the code or the git history.
2. Anything a visitor types (search, forms, the URL) being written into the page as HTML instead of plain text.
3. Sign-in or admin checks that run in the browser.
4. Database tables without row-level security or access rules, if there's a database.
5. Scripts or packages from outside the project: exact versions, and whether each is needed.
6. Whether .env is listed in .gitignore.

List each finding with the file, how serious it is, and a one-sentence fix. Then wait for my OK before fixing anything.

Fix the findings one at a time, most serious first, and check each in the browser. If the review finds nothing, don't relax: ask, “What would an attacker try first on this site?” and test that too.

Pin outside scripts

If your page loads a script from another site, such as a CDN, pin an exact version and add an integrity hash: a fingerprint the browser checks before it runs the file. If the file on the CDN ever changes, the browser refuses to run it. Ask your agent to add the hash. You'll use this pattern for the PDF library in Module 5.

A pinned script with an integrity hash
<script src="https://cdn.jsdelivr.net/npm/pdfmake@0.3.14/build/pdfmake.min.js"
        integrity="sha384-(the hash your agent computes)"
        crossorigin="anonymous"></script>
Fill the blanksExercise 1 of 2

Complete the .gitignore lines that keep local secrets and installed packages out of git.

/
Quick checkExercise 2 of 2

The review finds an API key you committed three weeks ago. You delete it from the code in today's commit. Are you safe?

Test it like a stranger

  • Open the live site in a private window, signed out of everything.
  • Right-click and choose View Page Source, then use Find (Cmd+F or Ctrl+F) to search for key, secret, password and token.
  • Type <b>hello</b> into the search box. If “hello” appears in bold, visitor input is being treated as HTML. Report it.
  • If you have sign-in or a database, try to reach owner-only pages and data while signed out, and again as a second test account.
  • Check the project's visibility setting on your builder or GitHub is the one you chose.
Write the rules down
Add the rules to your project's instruction file so every future session starts with them. Module 5 sets that file up properly; for now, a short Security rules section is enough: no secrets in front-end code, show visitor input as text, no new packages without asking, and never turn off a security rule to fix an error.
Definition of done0 / 7
Pick your track · finish either one
Steps · 0 / 5 done

  1. Answer the five questions

    Write one line per question, or ask the agent to answer them from the code and correct anything it gets wrong.

    VerifyYou have five short answers you agree with.

  2. Run the security review

    Send the review prompt from above. Read every finding before approving any fix.

    prompt
    Do a security review of this whole project. Don't change anything yet. Check for:
1. Secrets or keys anywhere in the code or the git history.
2. Anything a visitor types (search, forms, the URL) being written into the page as HTML instead of plain text.
3. Sign-in or admin checks that run in the browser.
4. Database tables without row-level security or access rules, if there's a database.
5. Scripts or packages from outside the project: exact versions, and whether each is needed.
6. Whether .env is listed in .gitignore.

List each finding with the file, how serious it is, and a one-sentence fix. Then wait for my OK before fixing anything.
    VerifyYou get a list of findings, each with a file, a severity and a fix, and nothing has changed yet.

  3. Fix findings one at a time

    Approve the most serious fix first, check the site, and commit. Repeat. In Claude Code, /security-review checks your branch's changes for vulnerabilities before you push; it needs an origin remote, such as your GitHub repository, to compare against.

    VerifyEach finding is fixed or deliberately accepted, with one commit per fix.

  4. Write the security rules

    Most agents read a file called AGENTS.md; you'll learn the details in Module 5. Edit the rules into your own words if you like.

    prompt
    Create an AGENTS.md file in the project root (or add to it if it exists) with a short "Security rules" section:
- No secrets in front-end code. Secrets go only in .env, which stays in .gitignore.
- Show anything a visitor types as plain text, never as HTML.
- No new packages or outside scripts without asking me first. Pin exact versions.
- Never turn off a security rule to make an error go away. Propose a narrower rule instead.
Commit it.
    VerifyAGENTS.md exists in the project root, committed, with a Security rules section.

  5. Test the live site like a stranger

    Push, wait for the deploy, then run the stranger tests above in a private window.

    VerifyNo secrets in the page source, HTML in the search box shows as text, and nothing private is reachable.
Check your understanding
Q1. Why is having no sign-in at all the most secure choice for Crumb & Co. right now?
Q2. Typing <b>hello</b> into your search box shows “hello” in bold. What does that tell you?
· Tick off the 5 step(s) above.
· Work through the 2 remaining exercises above (stuck? each one can show you the answer).
· Score 100% on the quiz.
Vocabulary in this lesson
AgentA model wired to tools and a loop: it reads, acts, checks the result, and goes again until the task is done or you stop it.AGENTS.mdThe instructions file at the repo root that every session reads first: commands, conventions, gotchas. CLAUDE.md in Claude Code.

Plain-English definitions from the AI Coding Dictionary.