Pro and Server compatibility
Check the differences before moving a profile between Pro and Server.
Both products consume .bb JSON, but run different engines. Create the profile in Pro's graphical editor, then use this table when exporting it for Server or comparing scan totals.
Active/passive profile types, payload rows, insertion IDs
Shared format; validate behavior with the actual request type.
Insertion ID 18
Pro editor All flag; Server maps it to entire body. Select individual controls for narrow checks; Entire body exports as 80.
Multi-step steps
Supported; configure each step, not only root fields.
showIssue
True suppresses; false permits reporting.
Header/body matching
Saved legacy OnlyHTTP / ExcludeHTTP flags and visible grep row options are different settings; validate the saved scope in both engines.
MatchType 1/2
String/regex modes, not boolean combinators. Keep row types consistent.
Regexes and replacement backreferences
Different implementations; Java compilation alone does not establish Server equivalence.
RedirType
Known numeric mapping differences; see redirects.
reuseCookie
Pro handles multi-step cookie reuse. Server parses it but does not currently execute the same reuse.
VariationAttributes, MatchType 7/8
Pro-specific variation analysis; no equivalent Server contract.
scanScope
Pro planning honors per-host selection, including before remote dispatch. Standalone Server does not enforce this field.
payloadsFile, grepsFile
Local file references; load the rows in Pro and distribute the complete saved profile.
Empty payload controls
The current editor omits blank payload rows when saving. Revalidate imported empty-payload control steps after editing.
sequence, Scope, Scanas, pathDiscovery and editor state
Do not treat them as a standalone Server execution contract.
{BC}
Pro Collaborator token; converted to Server {BH} with a configured provider. Missing provider affects coverage.
$BBOUNTY$ request span
Server active execution only. Not a Local Scanner profile variable.
Custom variables
Pro passes its configured variables with REST scans. MCP has no per-call token-map argument.
Rules
Pro-only .bb rule schema; not Server scan profiles.
Comparing engines
Use the same enabled profile objects, raw exchange, service/protocol, credentials, variables, payload strategy and budgets. Check the final mutated requests and matched evidence, including negative controls. Baselines, conditional steps, redirects, timing and asynchronous interactions can change packet counts even when both detect the same issue.
Do not “fix” an incompatible profile by deleting settings without understanding why they exist. Keep the original and create a clearly named variant if necessary.
Current limits outside profiles
REST requestPerSecond: 0 does not currently override the scan default, while MCP rps: 0 explicitly means unlimited. Pro rule And conditions and First Match actions have limitations documented in the rule reference. These are implementation boundaries, not guarantees the documentation can repair.
Last updated