[BUG] BCheck fails to log finding when initiated by "given request"

[ryman1]

Current behavior

This BCheck passes validation and correctly generates an issue when tested within BS Code, but using this BCheck via "Do passive scan" in Repeater or Proxy will fail to generate an issue, even when run against the same request that was used to successfully test the BCheck within BS Code.

metadata:
    language: v2-beta
    name: "POST request submitting URL parameter data"
    description: "Checks for POST requests submitting data via URL query parameters rather than the POST body"
    tags: "passive"

given request then
    if {latest.request.method} matches "POST" and {latest.request.url.query} matches ".+" then
        report issue:
            severity: low
            confidence: tentative
            detail: `The POST request is sending data via URL query parameters. This information could be logged by intermediate servers and web browser histories.\nDetected query parameter string: {latest.request.url.query}`
            remediation: `Consider changing the application to submit the information via a POST body if sensitive information must be transmitted.`
    end if

Here is an example request that successfully generates the BCheck issue when tested within BS Code but fail to generate an issue elsewhere in BurpSuite:

POST /test/log/?explode=events HTTP/1.1
Host: acme.com
Accept: */*
Content-Type: multipart/form-data; boundary=----geckoformboundary76b9be263432b1c840adfe4c9c54f856
Content-Length: 171
Priority: u=6
Te: trailers

------geckoformboundary76b9be263432b1c840adfe4c9c54f856
Content-Disposition: form-data; name="events"

blah
------geckoformboundary76b9be263432b1c840adfe4c9c54f856--

Expected behavior

This bcheck used to work correctly some time ago, and as far as I can tell, the BCheck should still work. The issue hinges on the given request then line. If I change this line to given response then, the BCheck works correctly in all areas of BurpSuite.

Environment details

• Burp version:v2025.7.2
• BCheck language version: v2-beta
• Operating system: MacOS Sequoia 15.5

Additional details

N/A

[Michelle-PortSwigger]

Hi

Thanks for getting in touch :)

A BCheck generated issue is curently classed as an ‘Intrusive’ scan check within the scan configs. While not all BChecks may be intrusive they can be, so for this reason if you use a scan config that only uses passive scan checks (such as the default Live audit from Proxy) they will not run.

You can create your own Live tasks and provide a scan config to look for BCheck generated issues, but you would need to be aware that this will run all enabled BChecks, not just passive ones.

I hope this helps to explain what you're seeing. Please let us know if you have further questions.

[ryman1]

Thanks, I understand now. It would be fantastic if there was a separate class of generated issue for bchecks tagged as passive (even if it had to come with a warning stating that there's no built-in enforcement of passiveness).

[Michelle-PortSwigger]

We've taken a closer look at this one and it turned out that this functionality had been implemented along the way, but at the time you contacted us there had been a regression which resulted in it not working.

If you check this out in the latest version it should be working again :)

[ryman1]

I'm still seeing the same behavior:

When given request then is used, the passive BCheck does not work correctly.
When given response then is used, the passive BCheck works correctly in all areas of BurpSuite.

[Michelle-PortSwigger]

Hi

Sorry for the misunderstanding. Checking versions where we have had changes to this, there do not appear to have been any changes to this specific scenario.

As the passive checks are looking for potential vulnerabilities in the target application then there is an assumption that there would be a response from the thing we're testing. So in this case you would use given response but you can check details in the request that was sent.

The given request option is generally used so that the request can be manipulated and used for active checks, such as adding extra headers as in this example that adds a collaborator payload:
https://portswigger.net/burp/documentation/scanner/bchecks/worked-examples/collaborator

I hope this helps to explain things.

[ryman1]

"As the passive checks are looking for potential vulnerabilities in the target application then there is an assumption that there would be a response from the thing we're testing. So in this case you would use given response but you can check details in the request that was sent."

There are scenarios, such as my own, where the target application's front end has a vulnerability that could be passively detected, even when a response is not received. For my detection, I'd like to know if the application is sending potentially sensitive data in the POST query string, even if a response is not received. That query string could still be logged in multiple locations.

[Michelle-PortSwigger]

This scenario might be best addressed via an extension rather than using a BCheck with the Scanner.

In an extension you could listen to the traffic coming from the client app to Burp and raise issues and if you don’t want those requests to reach the application the extension could also be coded to drop the request.

The BCheck will need the request to be issued (you could reduce how often this is sent by using a custom live task that just audits the one BCheck), whereas the the extension would give you the option of the request only going as far as Burp’s Proxy listener.