Navigate this article
The page loads, the form submits, and the demo works. That does not yet prove that the system protects data or recovers from failure. Let's use an order API as a review example.
Choose the flow that must not fail
Start with a short journey: sign in, find an order, and update its address. Record who may perform each action and the expected final state. Use a test copy without real customer data or credentials.
Before refactoring, record the code version and reproduce current behavior. Separate observed failures from assumptions and style preferences.
Test authorization without the interface
Hiding a button does not protect an API. Send a request directly using a session without permission, then a session from another company. The server must verify identity, company membership, and order access before returning or changing data.
The company identifier used to scope data must come from a server-validated identity. Do not trust a browser-supplied field to decide which account an operation belongs to.
# Test scenarios, not production commands
GET /orders/42 without a session -> access denied
GET /orders/42 as another company -> no data
PATCH /orders/42 without write permission -> no change
PATCH /orders/42 with invalid address -> validation failsA policy may return 403 or hide existence with 404. The important points are preventing disclosure and consistently enforcing the defined behavior.
Review failure paths and dependencies
Make an external integration unavailable in the test environment. Does the application report a useful failure? Stop retrying? Leave a partial record? Could a repeated request duplicate the action? These questions matter more than renaming a variable.
Look for secrets in source code, error messages containing personal data, and unjustified dependencies. Automated findings are a starting point: confirm whether each one affects the version and execution path the product uses.
- Timeouts and bounded retries for integrations.
- Input validation and handling of unexpected responses.
- Transactions and idempotency for actions with external effects.
- Useful investigation logs without tokens or unnecessary data.
Finish with a verifiable change
Pick a material risk, write a reproducing test, and fix it in a small change. Run journey tests, the build, and static checks. Record what was verified and what remains outside scope.
Before release, rehearse the migration and application rollback in a compatible environment. Reverting code does not automatically undo data changes. Define how to detect a regression and who can stop the release.
- Exercise deliverable: a cross-company access test, the fix, and evidence.
- Acceptance criterion: the authorized user completes the journey while another account cannot access the order.
- Next step: review a second flow without turning the review into a full rewrite.
Sources and further reading
Educational material. Validate examples in a test environment and adapt decisions to your project's context, risks, and responsibilities.
Share