Beginner Steps. Advanced AI.
Published guideUpdated
Chapter 16 of 20Build & check
Review security and privacy
Ask Codex what it checked, what it found, and what still needs attention. Keep the evidence.
A useful review names the risks and the limits. A clean scan is not a guarantee.
Follow the pictures
Illustrated examples. Your app may look different. Tap an image to enlarge it.
-
List what needs review
Use the security-review prompt to list the site’s features, services, accounts, and data.
Illustrated example - Start with
- Pages → Services → Accounts → Data
Look for: The review has a clear scope based on your actual website.
More help with this action
Use the scoped security-review prompt to ask Codex to list the actual site features, dependencies, external services, data collected, and privileged accounts. Include hosting logs and email enquiries, even when the pages themselves are static.
Review the systems you really use
- Ask Codex to inventory pages, dependencies, third-party scripts, external services, and accounts with privileged access.
- Include hosting logs and email enquiries in the data list, even though the website uses static pages.
- Keep accounts, databases, AI endpoints, and forms out of the inventory unless they actually exist. Adding any later requires a separate review.
You should now see: The review has a clear scope based on your actual website.
-
Check for exposed keys
Ask Codex to check files and history for exposed secrets. Revoke any leaked credential with its provider.
Illustrated example - If a key leaked
- Revoke it → Replace if needed → Clean up the exposure
Look for: Suspected secrets are reported without their values; exposed keys are disabled.
More help with this action
Review tracked files, Git history, and the generated dist folder for secrets, using OWASP secret-management guidance. Require a report that identifies locations without printing credential values. If a key was exposed, revoke or rotate it with its provider; deleting the current file alone is insufficient.
Deleting a file does not disable a key
- Have Codex inspect tracked files, relevant Git history, and the generated dist output. Reports should name locations and credential types without printing secret values.
- If a real credential was exposed, open its provider’s account controls and revoke or rotate it. Do not paste the value into the chat.
- Then review use of the old key and follow a scoped cleanup plan. Deleting the newest file or adding .gitignore does not erase old history or revoke access.
You should now see: Suspected secrets are reported without their values; exposed keys are disabled.
-
Review package findings
Run npm audit. Ask Codex to explain the findings, fix relevant issues, and rerun the checks.
Illustrated example - With Codex
- npm audit → Review findings → Fix and retest
Look for: Each relevant finding has a fix or a recorded assessment.
More help with this action
Run npm audit and have Codex explain each relevant advisory, affected component, and proposed fix. Apply reviewed updates on a branch, then rebuild and rerun tests. Avoid automatic forced upgrades without understanding their impact.
Assess before upgrading
- Ask Codex to run npm audit and explain the advisory, affected package, and likely impact for this project.
- Apply compatible, scoped updates on a branch. Avoid automatic forced upgrades that may change behaviour or break the build.
- Rebuild and rerun relevant tests. Record any unresolved issue and what remains unverified; npm audit covers known dependency advisories, not every possible risk.
You should now see: Each relevant finding has a fix or a recorded assessment.
-
Explain the data flow
List outside services and collected data. Use the EU information guidance to prepare accurate privacy information where it applies.
Illustrated example - Trace the data
- Website → Service provider → Privacy information
Look for: The privacy content describes the real services and data handling.
More help with this action
Inspect external scripts, embeds, fonts, and analytics. Keep only those you need. Record which providers receive visitor data and use their actual settings plus the EU personal-data information guidance to prepare an accurate privacy notice where applicable.
Use actual settings and providers
- Inspect scripts, embeds, fonts, and analytics with Codex. Remove what the site does not need.
- Record which providers receive information, what it is used for, and the actual retention settings. Include business email enquiries and hosting logs.
- Prepare privacy information matching these facts and the applicable requirements. A code scan or AI-written notice alone does not establish legal compliance.
You should now see: The privacy content describes the real services and data handling.
-
Check any optional form
If you added a form, check its server-side validation and verify a real test message arrives.
Illustrated example - Only if you added a form
- Submit → Server checks → Verify receipt
Look for: A form has receiving-service safeguards and real delivery evidence, or is recorded as not applicable.
More help with this action
If you added a receiving form service, use OWASP server-side input-validation guidance to require sensible input and length checks, alongside spam controls and failure handling. Recheck real delivery; browser-only validation can be bypassed. Keep credentials in the receiving service's secure configuration.
This action is conditional
- The first version uses an email link. If there is no backend form, record this part as not applicable.
- For a real form, require server-side input and length validation, spam controls, protected credentials, and useful failure states. Browser validation can be bypassed.
- Use an authorised test destination to verify actual receipt, plus invalid input and delivery failures. A website success message alone is insufficient.
You should now see: A form has receiving-service safeguards and real delivery evidence, or is recorded as not applicable.
-
Keep the review report
Save the dated review. Use the chapter checks to track fixes, open findings, and remaining decisions.
Illustrated example - Report contents
- Scope → Evidence → Open issues → Next action
Look for: The report records what was checked and what remains unresolved.
More help with this action
Save the dated report and review the security and privacy success checks. Fix unresolved high-impact findings before release, record the owner of remaining decisions, and use the EU disclosure guidance to review personal-data information where it applies.
Make the result reviewable
- Save a dated report covering review scope, methods, evidence, findings, fixes, and unavailable or unverified areas.
- Fix unresolved high-impact issues before release. Name an owner for remaining decisions and retain the evidence from checks after fixes.
- Review personal-data disclosures where applicable. Avoid absolute statements such as “fully secure” or “legally compliant” based on this review.
You should now see: The report records what was checked and what remains unresolved.
Why this step matters
Our static example has no visitor accounts, database, or AI endpoint. Its risks still include exposed secrets, vulnerable build dependencies, unwanted third-party scripts, and account access. Adding forms, payments, or accounts creates extra systems that need their own review.
A security skill guides the agent's work; it is not a security certificate. npm audit reports known dependency vulnerabilities and also has limits. Ask what was examined and what remains unverified, rather than accepting a universal claim that the site is secure.
Basics, explained
Dependency
Software your project relies on, such as Astro or a testing library. Its bugs and vulnerabilities can affect your project.
Secret rotation
Replacing a credential and disabling the old one, so a copied or leaked old value no longer grants access.
Server-side validation
Checking submitted data in the receiving service before accepting it. Checks in the visitor's browser are useful but can be skipped.
Ask your agent
PromptProduce a scoped security report
Use the website-security skill to review the actual Fieldnotes Studio implementation. Inventory features, dependencies, external services, and personal-data flows. Examine tracked files, relevant Git history, and dist for secrets without printing their values. Run npm audit and explain relevant findings. For any backend form, review server-side validation, abuse controls, credentials, and error handling. Write a dated report with evidence, severity, fixes, and unverified areas. Apply safe, scoped fixes and rerun checks. Do not claim complete security or legal compliance.Files & commands
shReport known dependency vulnerabilities without changing packages
npm auditIf something goes wrong
- Codex reports a leaked credential.
- Disable or replace it through the provider, then remove the exposure and review its use. Ask Codex for a scoped cleanup plan; do not paste the credential into the chat.
- npm audit offers a forced update that may break the site.
- Ask for the advisory and a compatible remediation plan. Test the proposed change on a branch and record any unresolved issue before deciding whether release is appropriate.
Official links & further reading
Personal notes
Add questions, decisions or ideas for your website. Saved in this browser when available; export your notes to keep a copy. Never enter secrets.
Downloads & saved progressGuide, notes and personal checks
Download the complete guide or export your notes from every chapter. Instructions last reviewed: .
Checks and notes stay in this browser, separately for each language. Export your notes to preserve them. Never enter API keys or other secrets here.
NotesNotes as Markdown
Clipboard access is unavailable. Copy the visible, selected text below using your keyboard or browser menu.
0 of 65 checks marked across the guide
These are your saved personal checkmarks. They do not run tests or verify security, and are separate from the chapter position bar above.
Starter filesWorking instructions and four skills
These templates give your agent a starting set of working instructions. Review them, adapt them to your website, and save each file at the exact path shown, relative to your project folder.
A downloaded skill is an instruction file. It does not install a test runner, run a security scan, or prove your site is safe. The guide shows how to set up and check that work.
Download the instruction files in the language of this guide. Keep the technical filenames and paths as shown.
Download all starter filesFileAGENTS.md
# Website working agreements
This project follows the website brief and acceptance criteria we have agreed with its owner. Use the existing technology choices unless a concrete requirement calls for a change.
## How to work
- For a substantial feature, explain the proposed changes and verification plan before implementing it. Complete authorized local work in small, reviewable stages.
- Read the files relevant to the task. Keep unrelated pages and configuration intact.
- Explain new technical terms in plain language when reporting to the owner.
- Use the repository's website-design, clean-code, website-testing and website-security skills when their workflows apply.
- Record important decisions and unresolved content in the project's notes. Do not invent business facts, endorsements or publishing rights.
## Verification
- Inspect package.json to find the actual build, type-check and test commands. Do not invent a successful check or create a meaningless test just to make a command pass.
- Run checks appropriate to the change. Local tests use disposable fixtures and have no production access; run them and repair failures caused by the requested change without asking at every step.
- Verify visitor interactions in a browser when browser tools are available. Report checks that remain unavailable or incomplete.
- Show the owner a working local preview and summarise changed behaviour, evidence and remaining limitations.
## Credentials and publication
- Keep API keys and other secrets out of browser code, prompts, logs and Git. Store local secrets in ignored files or the chosen secret store.
- Local build and test work is authorized. Publishing the site, sending a real message, processing a payment or changing production data requires the owner's authorization for that action.
- Preserve a recoverable working version before release. Describe how to restore it.
These are starter agreements for a new tutorial project. Adapt them to the owner's actual requirements and existing authorization.
File.agents/skills/website-design/SKILL.md
---
name: website-design
description: Develop or refine a website's visual direction and responsive interface from its brief, content and existing design. Use for page design or visual implementation.
---
Read the website brief and any existing design notes relevant to the requested page. Work within the user's brand, content and technology choices.
When establishing a new direction, propose typography, a small colour palette, a spacing rhythm and a sample page. Explain how these choices support the audience and main visitor action. Use real content to judge hierarchy and line lengths.
Implement reusable elements for navigation, headings, buttons and repeated content. Give primary actions a clear visual hierarchy. Preserve visible keyboard focus, readable contrast and usable labels. Design narrow screens alongside desktop screens; check long headings, navigation and tap targets in a browser.
Use semantic HTML before adding custom interaction. Keep motion optional and respect reduced-motion preferences. Use assets with known permission to publish; record their sources. Do not invent client testimonials, achievements or business facts.
Before expanding a design across all pages, show the first complete page at desktop and mobile widths. Describe the main design decisions and any unresolved content. When a browser tool is unavailable, report that visual verification is still pending.
File.agents/skills/clean-code/SKILL.md
---
name: clean-code
description: Implement or refactor website code into understandable components using the project's existing stack and conventions. Use for website implementation or maintainability work.
---
Read the relevant files and package scripts before choosing an implementation. Preserve working behaviour outside the requested change. Prefer the existing stack and dependencies when they meet the need.
Keep page content separate from repeated layout where that makes editing easier. Name components, variables and functions for their purpose. Use shared components for repeated navigation and page elements; avoid abstraction for a single trivial use.
Handle empty, invalid, loading and error states for interactions that need them. Use native browser controls and semantic HTML when they serve the interaction. Avoid fake form submission, simulated success messages and dead links.
Use type checking and the project's formatting or lint rules where configured. When adding a package, explain its purpose and any new maintenance or runtime requirements. Keep generated build output, dependencies and local environment files out of version control.
Run the existing checks relevant to the change, including a production build when output can change. Summarise changed behaviour, verification results and remaining limits. Explain the main files in plain language so a beginner can find and edit their content.
File.agents/skills/website-testing/SKILL.md
---
name: website-testing
description: Verify website changes through visitor journeys, appropriate automated tests and browser checks. Use when testing a website, investigating a failure or preparing a release.
---
Start from the brief and observable acceptance criteria. Inspect existing test and build commands; do not assume that a script exists. Choose checks based on the changed behaviour and the cost of failure.
Exercise the main visitor journey and affected links, navigation and forms. Include invalid input and relevant error states. For a contact form, verify actual delivery in the agreed test destination before reporting that it works. For an email link, explain that it opens the visitor's configured email app and does not send a message automatically.
Check narrow and wide screens in a browser. Include keyboard navigation, visible focus, accessible names, zoom and horizontal overflow. Automated accessibility results complement these manual checks and do not establish complete accessibility conformance.
Add automated tests for important behaviour or demonstrated regressions. Test observable outcomes and meaningful failure cases; avoid tests that merely repeat the implementation or match incidental wording. Use disposable test data and local fixtures. Never send real messages, charge payments or alter production data without the user's authorization.
Reproduce a failure, fix its cause and rerun affected checks. Report commands run, results, browser checks performed and anything not checked. A successful build shows that the site can be generated; verify visitor behaviour separately. Never report a check as passed when it was skipped or unavailable.
File.agents/skills/website-security/SKILL.md
---
name: website-security
description: Review a website's secrets, dependencies, inputs, permissions and deployment configuration, and repair scoped security findings. Use for requested security review or release preparation.
---
Identify the site's relevant surfaces: static pages, forms, backend routes, authentication, third-party scripts and stored data. Scope review to the actual architecture and authorized environment.
Keep credentials out of browser code, logs, prompts and Git. Distinguish build-time public configuration from server secrets. If a key was committed or exposed, stop using it, explain that deleting the file does not revoke the key, and have the owner revoke or rotate it before further use. Do not print the credential in your report.
Inspect applicable dependency advisories and assess whether the affected package and vulnerable behaviour are used. Repair within the project's compatible versions and rerun affected checks. Avoid automatic forced upgrades that may break the website.
For backend interactions, validate inputs on the server, encode output appropriately, and check authentication and authorization separately. Consider abuse controls for public forms or AI endpoints. An OpenAI API key belongs on the server; publishing a static site does not provide a secret server environment.
Check HTTPS and applicable security headers at the actual hosting layer. Collect only the data the feature needs, and explain its destination and retention. Do not claim legal compliance from a code scan.
Report each finding with its location, plausible impact, fix and verification. State review scope, tools used, unresolved findings and inaccessible surfaces. A clean scan is evidence about that scan's scope, not a guarantee that the website has no vulnerabilities. Do not scan third-party systems or deploy changes outside the authorized task.