02 / Security workflow

Security work that ends in a clear next step.

Plan authorized API security checks, review permission boundaries, preserve evidence, and verify fixes without confusing alerts with confirmed defects.

Translate a requirement into a testable boundary

Start with a business rule: a user can access their own account, an editor can change a permitted record, or a service can call only an approved operation. Identify the subject, action, and protected object. Then write a permitted case and a denied case using synthetic data.

OWASP's REST security guidance recommends access control at non-public API endpoints. Your assessment must still establish what access is appropriate for each role and operation. Authentication identifies the caller; authorization determines whether the action is allowed.

Keep authorization for the assessment explicit

Before a penetration test or a narrower scanner-assisted review, agree on the exact target, environment, methods, time window, and excluded third parties. Identify operations that could change data, send messages, trigger purchases, or consume shared resources. Obtain approval for the selected behavior rather than relying on a tool's reassuring mode name.

A security researcher or ethical hacker needs the same clear scope as an internal developer. Do not extend a review to unrelated systems or real customer records. Keep interruption and recovery procedures available to the operator supervising the exercise.

Review findings on three dimensions

Confidence

Can an authorized reviewer reproduce the observation? Does the evidence identify the correct environment and role? Missing context reduces confidence; it should not be replaced with a model-generated explanation.

Impact

What data or operation does the behavior affect? Ask the application owner how the observed boundary relates to the real workflow. Avoid inferring business impact from a route name alone.

Next action

Specify who needs to confirm, repair, accept, or retest the issue. A ticket should distinguish proposed remediation from verified behavior. Preserve the reason for a rejected finding or temporary exception.

Close the loop without hiding limitations

Retest the narrowly scoped defect and its legitimate counterpart after a repair. Record the application revision, test identity, expected result, and observed result. Keep cancelled runs, missing authentication, and excluded operations visible.

Our sample report shows this structure with invented staging data. The API scanner guide provides the inventory-first approach, while firewall guidance explains how traffic controls fit beside application-level decisions.

Primary references

Read the documentation that matches your tool, framework, and deployment. These sources provide context; they do not establish coverage of your environment.