Skip to main content

Findings

A black-box pentest detects vulnerabilities you can reach over HTTP. For each confirmed issue, AISafe stores the complete request and response as content-addressed evidence and links the finding to that captured exchange.

Categories detected​

The agents test OWASP Top 10 categories and the application's specific logic:

  • Injection: SQL injection, JSON operator injection, command injection, template injection, and cross-site scripting (reflected, stored, DOM-based). Tests cover discovered query and path inputs as well as form and JSON bodies, including POST and PATCH requests. Statistical database checks compare repeated successful baseline and contrasting conditions on the same operation while preserving the other request fields. Filter rejections and rejection-only delays cannot confirm injection. AISafe captures the requests and responses that establish the result.
  • Server-side request forgery (SSRF): internal network access through user-controlled URLs. The agents test whether user input can steer outbound requests to internal services.
  • Broken access control: insecure direct object references (IDOR), missing authorization checks, privilege escalation. The agents test whether an authenticated user can reach resources or actions outside their scope. For signed-in object reads, the validator compares direct access with the application’s collection: a JSON listing, an HTML page linking the objects, or a GraphQL listing query on the same origin. JSON detail and listing responses can use different identifier field names when their values identify the same object. A direct read is not reported when the reader's normal collection already contains the same object with matching stable fields. Sharing permission also comes from the recorded access policy. Refusing anonymous access alone does not establish that signed-in users cannot read another user's object. Selector-free collections and signed-in self records use their concrete request and stable record identities instead of an invented object selector.
  • Authentication bypass: session fixation, token manipulation, brute-force susceptibility. The agents probe the authentication mechanism for weaknesses that allow impersonation or session takeover.
  • Information disclosure: verbose errors, exposed debug endpoints, backup files. The agents look for responses that leak details about the application or its infrastructure. A credential finding requires evidence that an unauthorized recipient received a working credential. Credentials issued to a test session and returned only to that account are expected authentication output. AISafe checks session credentials for disclosure to anonymous readers or another account. Provider keys and private keys found in responses remain exposure candidates when the crawler is signed in. Each distinct credential value is checked once per assessment.
  • Business logic flaws: price manipulation, race conditions in transactions. The agents reason about the intended workflow and look for ways to subvert it for advantage.
  • Browser origin and session policy: credentialed cross-origin reads, open redirects, actionable framing, an explicitly disabled HTTPS-only policy and script-readable login cookies. AISafe runs these checks once per web origin. It reports a finding only when the browser or target response shows the effect. A missing header by itself is not reported as a vulnerability.

A test stays inconclusive when its evidence does not establish the proposed defect. A fresh HTTP callback proves a server-side request; triage judges whether the application was meant to make it. DNS alone cannot prove a fetch, and an ordinary URL callback cannot prove injection or script execution. Script execution must occur in the target document's effective security origin. Session tests compare authenticated-only content, and credential checks include an invalid-token control. Cross-site form checks require values an attacker could obtain. State-change checks require a stable control, and attack-chain controls establish whether the final effect depends on the captured capability. Triage judges whether exposing it violated the application's policy.

Evidence​

Each confirmed finding carries:

  • Black-box evidence: the observed result and the validator's captured request and response, exactly as they were sent and received, with the full URL, the payload and every header. This is what proves the target's behavior.
  • Proof-of-concept: a standalone script that sends the validator's requests and checks for the same result. Triage runs it against your system before the finding is published, and includes it only when its output showed that result.
  • Reproduction steps: the requests that proved the issue, in order, with the test user each was sent as and what to look for, so you can verify it and hand it to the engineer fixing it.
  • Impact assessment: what an attacker could achieve, grounded in the observed response. This helps you rank the finding against others.
  • Suggested fix: concrete remediation tailored to the vulnerability type and the application's behavior.

Where possible, the agents map each finding to a standard category (CWE or OWASP) for cross-referencing with your existing security tracking and compliance frameworks.

Severity and status​

Each finding carries a severity and a lifecycle status you control.

  • Severity runs from Critical to Info. The discovering agent assigns an initial rating, and the triage pass refines it by exploitability, impact, and context. See Triage: severity levels.
  • Status starts as open. Your reviews move it to confirmed, false positive, accepted risk or duplicate. AISafe sets fixed or not fixed when it re-tests the finding. See Triage.

Before triage, AISafe merges candidates whose evidence establishes the same root cause at the same place. In a scan with validator-confirmed live proofs, repeated proofs of the same weakness at the same input and delivery site become one candidate even when different tests found them. A triage agent then re-examines each candidate's evidence, confirms or rejects it, and assigns a confidence score. You make the final decision on every finding. See Triage.

If triage rejects a combined candidate, AISafe reviews its independently validated members separately. Rejecting a broader attack chain does not discard a weakness already proved on its own.

AISafe searches for attack chains where one proved step supplies a value or access that a later step needs. A refused object read can serve as the final control when a preceding step may unlock it. The validator must prove the complete chain and its controls before it becomes a finding.

An attack-chain finding retains the requests for every step and links the affected operations in Documentation and coverage. Its primary affected URL identifies the first exploited operation. Review of a role-escalation chain includes the account that gained the role and the separate, unpromoted account used as a control.

Documentation and Artifacts​

Web application assessments with a recorded live model also provide Documentation and Artifacts. Documentation shows services, entities, data flows, trust boundaries, threats and entry points. Entry-point details include recorded parameters and the responses observed for each role and session.

Artifacts shows coverage by operation and attack class, with confirmed, refuted, inconclusive and unchecked results. Coverage retains the versions tested even when an operation changes or is removed, and shows Needs review when those versions require review. Methodology and Audit record show the recorded rounds, agents, validators, test-user sign-in outcomes and session states. The overviews include HTTP activity and execution counts. A field an older run did not record stays absent, and assessments without source do not show source-file charts or code spans.

Documentation, Threats, Entry points and Checklist read one application model. If a required section is unavailable, the page reports that state instead of showing an empty section.

For a finding proved by a state change, the evidence identifies who took the action and who read the result, including when both used the same session. A changed role or other stored value establishes that change; it does not by itself show that another user saw it or that the new capability was used.