How to investigate and fix a security finding¶
A finding points to code that needs investigation. Whether it is exploitable depends on the inputs, permissions, framework, configuration and route through the application. Use the explanation and examples to understand the pattern, then verify the behavior in your own environment.
1. Establish the boundary¶
Record the affected version, component and operation. Trace where data originates, which transformations happen and which sensitive operation receives it. A source might be a request parameter, database record, uploaded file or third-party response. A sink might be a query, file write, template, network request or authorization decision.
Check whether an attacker can influence the value and reach that path. Keep the scanner rule, file location and reproduction steps alongside the finding. A CWE describes a weakness class; it does not establish a severity score or prove exploitation.
2. Choose a fix for the actual context¶
Start with a reviewed vulnerability guide and the relevant language guide. Check the runtime and library assumptions above the sample. Prefer removing the dangerous operation or separating data from instructions: parameterized queries, fixed templates, narrow schemas and explicit authorization.
Examples are deliberately small. They illustrate a boundary, rather than a complete production application. Authentication, error handling, dependency updates, quotas and deployment policy may still be needed. An unreviewed legacy reference has an explicit review notice and may contain older APIs; compare its advice with maintained framework documentation before use.
3. Test both allowed and rejected behavior¶
Use a local test environment and synthetic records. Verify an ordinary allowed request, a boundary value and an input that should be denied. For access controls, use two fictional users with distinct resources and prove that one cannot read or modify the other's data. For injection, verify that input stays data and does not alter the operation.
Do not send test exploits to systems you do not own or have permission to assess. Avoid real credentials, customer data and external callback services in regression tests. Record the expected response and any side effect, such as a file created or a query executed.
4. Verify and track the result¶
Run the relevant unit or integration tests and rescan the same code version. A disappearing finding is useful evidence, but is not a substitute for verifying the corrected behavior. Document any residual risk, compensating control or false-positive decision with a reason and a review date.
For a confirmed false positive, preserve the evidence explaining why the input cannot reach the sensitive operation or which control is effective. Scope any suppression narrowly so that future unsafe uses remain visible.
Understanding coverage¶
This knowledge base covers secure coding topics across several languages. A guide's presence does not mean every Offensive360 product detects every variation. Native rules, optional AI review, dependency analysis, web scanning and packaged mobile analysis have different inputs and limits. See supported languages and scope before selecting a scan.