Business web security begins with controlling who can read and change each record. Authentication identifies a caller; authorization determines what that caller may do. A logged-in user should not gain access to another customer's data by changing a URL parameter.
Test the record boundary
For a hypothetical customer portal, create separate users and records in an authorized test environment. Attempt reads, edits, downloads and exports across ownership boundaries. Repeat the check for direct API calls, not only navigation links.
OWASP authorization guidance recommends least privilege, deny-by-default behavior and permission checks on each request. Hiding an admin button is a UI decision, not a server-side control.
| Surface | Acceptance check |
|---|---|
| Record endpoint | Unauthorized caller cannot access another record |
| File download | Permission applies to the file as well as its page |
| Mutation | Role, ownership and valid transition are checked |
| Export | Only permitted records and fields are returned |
| Service account | Access is limited to its assigned workflow |
Validate meaning as well as format
OWASP input validation separates input validation concerns. Check type, length, accepted values and business rules. A well-formed amount can still be unacceptable, and a syntactically valid identifier can still belong to someone else. Use parameterized queries rather than assembling SQL from input.
Make operations part of the plan
Keep credentials outside public code and logs. Maintain dependencies, monitor failures and verify recovery from a backup. Rate limits help manage abuse but do not replace permission checks. Differentiate local tests, staging acceptance and actual production verification.
What should an external review deliver?
Specific affected paths, reproducible authorized test cases, business consequences and bounded fixes. No technology label establishes security by itself. For custom software, define sensitive workflows and permission rules as acceptance criteria before launch.