Share Burp Suite Projects Across Your Team (2026)

Sharing Burp Suite projects across a team is surprisingly less about a central server and more about carefully managing shared state and avoiding accidental overwrites.

Let’s see it in action. Imagine two testers, Alice and Bob, working on the same target application. Alice has Burp Suite open, actively scanning a login form. She’s found a potential SQL injection vulnerability and is meticulously crafting follow-up requests.

# Alice's Burp Project (Local File: alice_project.burp)
# Target: https://example.com/login

# Proxy History (snippet)
GET /images/logo.png HTTP/1.1
Host: example.com
...

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Cookie: sessionid=abcdef12345;

username=admin&password=' OR '1'='1
...

# Intruder (snippet)
Target: https://example.com/login
Payloads:
  - ' OR '1'='1
  - ' OR '2'='2
  - ...
Positions: Password field
Status: Running

Now, Bob needs to pick up where Alice left off, or at least see her findings. If they were just using separate local projects, Bob would have no visibility into Alice’s work. This is where sharing comes in.

The core problem Burp Suite’s project sharing solves is synchronizing the state of an active security assessment. This state includes:

Proxy History: Every request and response that passes through Burp.
Target Scope: What parts of the application are being tested.
Scanner Issues: Vulnerabilities found by the active scanner.
Intruder/Repeater Configurations: Saved attack setups and custom requests.
Session Handling Rules: How Burp maintains authenticated sessions.
Extensions: State managed by installed Burp extensions.

The most common and robust way to share is by using Burp’s built-in project file saving and loading mechanism, combined with a shared network location.

Scenario: Alice shares her progress with Bob.

Alice Saves: Alice has been working for a few hours. She navigates to Project -> Save project. She chooses a network share accessible to Bob, naming it shared_project.burp.
```
# Alice's action:
# File -> Save project
# Path: \\networkshare\burp_projects\shared_project.burp
```
This command serializes all of Alice’s current Burp state into a single file.
Bob Loads: Bob starts his Burp Suite. He navigates to Project -> Open project. He selects \\networkshare\burp_projects\shared_project.burp.
```
# Bob's action:
# File -> Open project
# Path: \\networkshare\burp_projects\shared_project.burp
```
Bob’s Burp Suite now mirrors Alice’s state at the time she saved. He’ll see her proxy history, her saved Intruder attacks, and any scanner findings she’d already generated.

The danger here is concurrency. If Alice and Bob both save their projects to the same file without coordinating, one person’s work will overwrite the other’s. Burp Suite does not do live, real-time synchronization like Google Docs. It’s a snapshot.

Best Practices for Sharing:

Designated Saver: Have one person (or a rotating role) be responsible for periodically saving the master project file to the shared location.
Clear Naming Conventions: Use descriptive names for project files, perhaps including a date and time, or the primary target. webapp-v2-20231027T1030.burp.
Regular Saves: The designated saver should commit their work frequently, especially after major findings or configuration changes.
Individual Local Copies: Encourage team members to also save their own local copies of the project file periodically. This acts as a personal backup and a way to revert if a shared save causes unexpected issues.
Understand What’s Shared: Be aware that Burp Suite project files contain all active state. This includes potentially sensitive details like authentication tokens in history, saved credentials in extensions, and custom wordlists. Ensure the shared location is secured appropriately.

The one thing most people don’t realize is that the Burp Suite project file is not just a configuration dump; it’s a complete serialization of the entire running state of the Burp instance at the moment of saving. This means if an extension is actively running a complex analysis or has a large in-memory data structure, that entire state is captured and restored. This can lead to very large project files and potentially long load/save times if not managed.

The next concept you’ll likely encounter is how to manage concurrent scans across a team, which Burp Suite’s native project sharing doesn’t directly address.