The handbook/Secure Coding with Claude Code: Login, Access Control and Input Validation
Reading settingsMy workspaceOfficial docs ↗

Intermediate • After the basics

Build protections
into your application.

Turn authentication, authorization, input validation, and database safety into concrete implementation tasks and repeatable tests.

STEP-BY-STEP HANDBOOKFor projects with forms, accounts, or data

Before you start: Know how to use a practice branch and run your app’s tests. Skip controls that do not apply to your project. These lessons use two fake test accounts, never another person’s live account.

Quick scan: Check identity, then permission. Validate on the server. Keep input separate from database commands.

1. Separate identity from permission

Authentication asks who someone is. Authorization asks what they may do. Hiding an Edit button does not protect the underlying request. Enforce ownership and permissions on every protected server request.

Ask Claude to help

Claude Code conversation, in your own practice project
Inspect the current repository and its instructions first. Work only on this project in a local or test environment. Explain the risk and propose a small plan before editing. After I approve that plan, implement it and run focused checks. Do not deploy, change production data, spend money, or broaden account access without separate approval. Inspect the current authentication provider and authorization rules. Reuse supported provider features. Enforce ownership and role checks on server routes; deny access by default. Propose MFA for privileged accounts with recovery steps before enabling it. Do not create a custom password system.

Check the result: In staging, confirm signed-out users are denied. Verify test user A cannot read or change test user B’s record by changing an ID. Test ordinary and administrator roles separately, including expired sessions.

2. Validate data where it enters the server

Validation checks type, size, format, and allowed values. Browser checks improve usability, but requests can bypass them. Output encoding renders user text safely. HTML sanitization is needed only when you intentionally permit rich HTML.

Ask Claude to help

Claude Code conversation, in your own practice project
Inspect the current repository and its instructions first. Work only on this project in a local or test environment. Explain the risk and propose a small plan before editing. After I approve that plan, implement it and run focused checks. Do not deploy, change production data, spend money, or broaden account access without separate approval. Locate server request boundaries. Apply the project’s validation tools to types, length limits, allowed values, and business rules. Use safe text rendering and context-appropriate encoding. If rich HTML is supported, use a maintained sanitizer. Return useful errors without internal details.

Check the result: Test empty, oversized, malformed, and unexpected values directly against the test API. Verify harmless HTML-like text displays as text where HTML is not allowed. Confirm valid names and ordinary punctuation still work.

3. Keep data separate from commands

Parameterized queries pass values separately from database instructions. Concatenating a user’s text into a query can change what the query does. Database policies must also protect each user’s records.

Ask Claude to help

Claude Code conversation, in your own practice project
Inspect the current repository and its instructions first. Work only on this project in a local or test environment. Explain the risk and propose a small plan before editing. After I approve that plan, implement it and run focused checks. Do not deploy, change production data, spend money, or broaden account access without separate approval. Inspect data access and use bound parameters or the existing safe query builder. Preserve least-privilege database access. Review row ownership policies where supported. Propose migrations separately with backup and rollback steps before execution.

Check the result: Run focused database tests with ordinary values and hostile-looking text in an isolated test database. Confirm the value remains data and that cross-account reads and writes fail. Inspect migration effects before approval.

Next: Before a public launch or sensitive integration, work through the advanced review checklist.

References

Reviewed September 24, 2026. These links explain the underlying controls; a copied prompt is not a security certification.

Was this chapter useful?

Report an error

Votes are shared only if you enable optional measurement in Privacy settings.

CONTINUE THE GUIDESecurity: advanced

Edit this example

Changes here affect this copy only. Nothing runs from this site. Closing this window discards your edits.

Search the field guide

Search all chapters and FAQ answers. Use Tab to reach a result and Enter to open it.