# Retrieving a Concise False Positive Summary

## Overview

When Mobb marks an issue as a false positive, it generates a detailed `fpDescription` explaining exactly why the issue is not a real vulnerability. These descriptions are intentionally thorough — often spanning multiple paragraphs — to provide developers and security engineers with a complete rationale.

However, in many integration scenarios, a full-length explanation is impractical. For example:

* **SAST scanner suppression comments** embedded directly in source code have strict character limits.
* **Ticketing systems** (e.g., Jira, Linear) benefit from a concise one-line summary rather than a wall of text.
* **Dashboards and reports** that surface FP justifications inline need a short, readable blurb.
* **CI/CD pipeline logs** where brevity improves readability.

The [`GET /api/rest/fp-summary`](https://apidocs.mobb.ai/mobb-rest-api#tag/issues/get/api/rest/fp-summary) endpoint solves this by returning a trimmed version of the false positive description — capped at 280 characters.

***

## Step 1: Identify the False Positive Issue and Capture Its `fpId` ([`GET issues v5`](https://apidocs.mobb.ai/mobb-rest-api#tag/issues/get/api/rest/v5/issues))

Query the v5 issues endpoint, filtering by your fix report ID. In the response, look for issues with `"state": "FalsePositive"` — these entries include an `fpId` field that uniquely identifies the false positive record.

```bash
curl -X GET "https://api.mobb.ai/api/rest/v5/issues?fixReportId=a210dd07-a9df-4c2b-ad89-22343a580148" \
  -H "x-mobb-key: YOUR_API_KEY" \
  -H "Accept: application/json"
```

**Sample Response (relevant fields shown):**

{% code overflow="wrap" %}

```json
{
    "getIssuesApiV5": {
        "vulnerability_report_issue": [
            {
                "id": "2df47df3-b139-4d6b-bf04-ac06bc514ef4",
                "vendorIssueId": "257",
                "issueType": "XSS",
                "severity": "error",
                "issueLanguage": "javascript",
                "state": "FalsePositive",
                "createdAt": "2026-03-04T18:10:11.439502+00:00",
                "fingerprintHash": "3c448e02f9ce40437d49864480ddffae",
                "vulnerabilityReportIssueTags": [
                    {
                        "vulnerability_report_issue_tag_value": "FALSE_POSITIVE"
                    }
                ],
                "fix": null,
                "fpId": "e0d33c87-8602-4267-a720-190ef66c8a54",
                "fpDescription": "This issue is a false positive. The flagged code at lines 430-442 involves retrieving a user record from the database using `req.params.userid`, updating the user's status field with a validated value from `req.body.status`, and then saving the record. On line 442, if an error occurs during the save operation, `res.status(500).send(err)` is called. This is NOT an XSS vulnerability because:\n\n1. The `err` object is a server-side error object generated by the database/ORM layer (likely Mongoose based on the `.save()` pattern), not user-controlled input.\n\n2. The `req.params.userid` is used only for database lookup and is never rendered in HTML context in this code path.\n\n3. The `req.body.status` value is strictly validated on lines 425-428 to only allow 'active' or 'inactive' before being assigned to the user object.\n\n4. The error response on line 442 sends the error object directly via Express's `res.send()`, which will serialize it as JSON or text. This is not a DOM manipulation or HTML rendering context where XSS could occur.\n\n5. While sending raw error objects to clients is poor practice from an information disclosure perspective, it does not constitute XSS as there is no user-controlled data being reflected into an HTML/JavaScript execution context.\n\nThe trace does not show any path where user input reaches a DOM sink like innerHTML, document.write(), or similar XSS-prone methods."
            }
        ],
        "hasNextPage": false
    }
}
```

{% endcode %}

Note the `fpId` value (`e0d33c87-8602-4267-a720-190ef66c8a54`) from the response — you will use this in the next step.

***

## Step 2: Retrieve the Concise FP Summary ([`GET fp-summary`](https://apidocs.mobb.ai/mobb-rest-api#tag/issues/get/api/rest/fp-summary))

Pass the `fpId` captured in Step 1 to the `/api/rest/fp-summary` endpoint to retrieve a condensed, 280-character-maximum summary of the false positive justification:

```bash
curl -X GET "https://api.mobb.ai/api/rest/fp-summary?fpId=e0d33c87-8602-4267-a720-190ef66c8a54" \
  -H "x-mobb-key: YOUR_API_KEY" \
  -H "Accept: application/json"
```

**Sample Response:**

{% code overflow="wrap" %}

```json
{
    "getFpSummary": {
        "fpId": "e0d33c87-8602-4267-a720-190ef66c8a54",
        "fpDescriptionShort": "[marked FP by Mobb] False positive flagged as XSS; error is DB/ORM-generated, params are non-HTML rendered, body input is validated, and error is JSON serialized, not reflective in HTML/JS context."
    }
}
```

{% endcode %}

The `fpDescriptionShort` field contains the concise summary, ready to be embedded in code comments, tickets, or pipeline output.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.mobb.ai/mobb-user-docs/mobb-rest-api/rest-api-common-deployment-scenarios/retrieving-a-concise-false-positive-summary.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.