# BChecks: a shared library of Burp Suite scan checks, with the warranty left out on purpose > BChecks is PortSwigger's official collection of custom scan checks written in a purpose-built language, usable in both Burp Suite Professional and Burp Suite DAST. The repository sorts checks into examples, vulnerability classes, checks with a CVE and an archive, and it states plainly that the checks are written by third parties and carry no warranty. **PortSwigger/BChecks** — BChecks collection for Burp Suite Professional and Burp Suite DAST - Repository: https://github.com/PortSwigger/BChecks - Website: https://portswigger.net/burp/documentation/scanner/bchecks - Stars: 805 · Forks: 133 - Language: Unknown - License: LGPL-3.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/portswigger-bchecks ## A check language that only exists inside Burp BChecks is the official BChecks repository from PortSwigger, and it contains a collection of custom scan checks written in the BChecks language, developed by both PortSwigger and the community. The language is the point, and it is the boundary. The README notes that this repository only contains scan checks written in the custom BChecks language, and that for checks written in Java the place to look is the Bambdas repository, under its CustomScanChecks directory. So the extension ecosystem for Burp has two halves, and this repository is one of them. What the language buys you is portability of the check, not of the product. A BCheck can be imported and used in both Burp Suite Professional and Burp Suite DAST, which means a detection written once can run in a desktop scanner and in a hosted scanning service. For teams that run both, that is the argument for using this language at all. The authoring story is tied to the professional edition. The README says that to write and test your own BChecks, using Burp Suite Professional is recommended, because it includes a built-in editor with syntax highlighting and testing tools. The documentation set behind that claim is a definition reference listing the keywords available when writing a BCheck, worked examples corresponding to real-world use cases, and a video overview of the functionality available in the BCheck v2 beta language. The repository also carries a BCheckChecker jar at the root, which is the sort of artefact you would expect for a collection that has to be checked automatically rather than only read. ## The directory layout sorts checks by what they look for The repository is organised into four directories plus an archive, and the organisation is the documentation. The examples/ directory holds a small set of checks meant to get you started: Blind SSRF via out-of-band detection, Exposed git directory, Leaked AWS Tokens, Log4Shell via out-of-band detection, Server Side Prototype Pollution and Suspicious Input Transformation. The README describes them as example BChecks to help you get started, and the files in the directory carry the same names with a .bcheck extension. The vulnerabilities-CVEd/ directory is for checks that look for specific vulnerabilities which have a CVE. That is a narrower and more useful category than it sounds: a check tied to a published advisory has an expected request and an expected response, which makes it easier to review and easier to reason about when a scan result says nothing. The vulnerability-classes/ directory is for checks that look for vulnerability classes as opposed to discrete vulnerabilities, which is the harder class to write and the more valuable one to reuse. The other/ directory holds checks created by the community that the maintainers did not imagine, and the archived/ directory preserves checks for users with older versions of Burp Suite. That last directory is worth noting on its own. It implies the checks carry a compatibility expectation, and that when the language or the product moves on, old checks are set aside rather than deleted, because somebody is still running an older version. ## Importing into Professional and DAST is the same artefact The resources section of the README is organised by task rather than by product, which tells you how the extension system is meant to work in practice. Importing has a page for custom scan checks in Burp Suite Professional and a page for adding BChecks to Burp Suite DAST. Using them in a scan has a page for adding custom scan checks to scans in Professional and a page for scanning with extensions in Burp Suite DAST. The same four operations, once in the desktop product and once in the hosted service, and the same artefact on both sides. That matters for how a team runs checks. A detection can be developed on a laptop, imported into a DAST site configuration, and then applied to a recurring scan against a web application or API, without rewriting it. The site settings documentation for scanning with extensions is what an engineer would read to set that up. The project also treats the checks as a public, shared resource rather than a support article. The README has a section on community submissions, describing BChecks as a community-driven effort and encouraging people to share their own checks and to improve the existing ones, with the process described in CONTRIBUTING.md. There is a code of conduct in the repository, and the blog links cover a walk through of the top community created checks and a case study of Sprocket Security using BChecks for offensive security testing. In other words, this repository is positioned as an ecosystem with an upstream reviewer, not as a set of sample snippets in a documentation page. ## The disclaimer is the most important line in the README The final section of the README is short and worth quoting in substance. BChecks are written and maintained by third-party users of Burp. PortSwigger reviews the pull requests for new community-created scripts before they are added to the repository. However, PortSwigger Web Security makes no warranty about their quality or usefulness for any particular purpose. Three things follow from that wording. The review is a review of the pull request, not an audit of the detection logic, and a check that passes review can still be a bad check. The authorship sits with the community, which is why the repository is organised around contribution rather than around a supported catalogue. And the absence of a warranty is a statement about the relationship between a vendor and third-party scripts running inside its product. For a user this has a practical consequence. A check that fires is a signal to investigate, not a finding to report, and a check that does not fire is not evidence of absence. If your process depends on the results, you have to look at what each check actually asserts, and the worked examples and definition reference in the documentation are the place to start. On the licensing, the repository is LGPL-3.0, with the LICENSE file at the root of the repository. Read it for the terms that apply if you redistribute or modify the checks, and this is not legal advice. The project has no GitHub releases, and the last push to the repository was on 2026-10-07 with the repository not archived, so the collection grows through the main branch rather than through tagged versions. ## Where BChecks is the wrong tool The first wrong fit is a team that writes Java. The README is explicit that this repository only contains checks in the custom BChecks language and points to the Bambdas repository for Java based checks. If your team's existing scanner extensions are Java, adding a second language for the same purpose is a decision to make deliberately, and the README's routing is a hint that the two ecosystems are not merged. The second is a scanner that is not Burp. A BCheck is loaded by Burp Suite Professional or Burp Suite DAST, and it is written in a language specific to those products. If your scanning is done with a different tool, a check written here does nothing for you, and the value of a community catalogue disappears with the platform. The third is a compliance process that wants a guarantee. The disclaimer is explicit, and the checks are third-party code that runs with the permissions of your scanner against systems you are authorised to test. A process that treats a check in this repository as a validated control is misreading what the repository is. The fourth is an expectation of coverage in the other direction. A missing check is not a signal. The repository is organised around what contributors have written, and the vulnerability classes directory is by definition incomplete, because the set of vulnerability classes is large and the contributors are volunteers. The fifth is using the examples as production checks. The examples directory is explicitly a starting point, covering familiar problems such as an exposed git directory or a leaked AWS token, and it is written to be read and modified rather than to be a vetted detection set. The archived directory is the same idea for old versions. What the repository is actually good for is a different thing: it is a way to read how other people express a detection, which is often more useful to a tester than the detection itself. ## Conclusion BChecks fits a security tester who wants a reusable library of detection logic for Burp Suite Professional or DAST rather than writing every check from scratch. It does not fit a team that needs Java checks, since those live in the separate Bambdas repository, and it does not fit a compliance process that treats a PortSwigger check as a guarantee. Before importing anything, read the disclaimer and check the check yourself, because the repository states that PortSwigger makes no warranty about the quality of community checks. ## FAQ ### What is BChecks? It is the official BChecks repository from PortSwigger, a collection of custom scan checks written in the BChecks language, developed by both PortSwigger and the community. The checks can be imported and used in both Burp Suite Professional and Burp Suite DAST. ### How are the BChecks organised in the repository? There are four directories: examples for getting started, vulnerabilities-CVEd for checks tied to a specific CVE, vulnerability-classes for checks aimed at a class of vulnerability, and other for community checks the maintainers did not imagine, plus archived for checks kept for users of older Burp Suite versions. ### Where do I find Java-based custom scan checks? The readme says this repository only holds checks written in the custom BChecks language, and points to the PortSwigger bambdas repository, under its CustomScanChecks directory, for checks written in Java. ### Does PortSwigger guarantee the quality of the BChecks? No. The disclaimer states that the checks are written and maintained by third-party users of Burp, that PortSwigger reviews the pull requests before they are added, and that PortSwigger Web Security makes no warranty about their quality or usefulness for any particular purpose. ### What licence does the BChecks repository use? The repository is licensed under LGPL-3.0, with the licence file at the root of the repository. ## Sources - [Issues](https://github.com/PortSwigger/BChecks/issues) - [License: LGPL-3.0](https://github.com/PortSwigger/BChecks/blob/main/LICENSE) - [PortSwigger/BChecks on GitHub](https://github.com/PortSwigger/BChecks) - [Project website](https://portswigger.net/burp/documentation/scanner/bchecks) - [README](https://github.com/PortSwigger/BChecks/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/portswigger-bchecks