Intermediate • After the basics

Build protections
into your application.

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

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.

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

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.

Copy includes the shared safety instructions above.

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

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.

Copy includes the shared safety instructions above.

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

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.

Copy includes the shared safety instructions above.

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

• OWASP Foundation. (2025). OWASP Top 10:2025. https://top10.owasp.org/2025/
• OWASP Foundation. (n.d.-a). Authentication Cheat Sheet¶. Retrieved September 24, 2026, from https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
• OWASP Foundation. (n.d.-b). Authorization Cheat Sheet¶. Retrieved September 24, 2026, from https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
• OWASP Foundation. (n.d.-c). Input Validation Cheat Sheet¶. Retrieved September 24, 2026, from https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html