Security

How BroadSQL protects the credentials it stores, and what's still your own responsibility.

The Connections Definition File (CDF)

Every connection you define (JDBC URL, username, password, everything) lives in the CDF, an H2 database file encrypted with H2's built-in file encryption (CIPHER=AES on the JDBC URL, verified directly against the bundled H2 2.3.232 driver's own source: it implements AES-128, not a larger key size, so that's the number to cite if you need one for a compliance questionnaire).

The master password unlocks the whole file. Internally, BroadSQL uses the same master password as both the file password and the database's own admin password; there's only one password to remember, not two.

What this means in practice: the CDF file is safe to copy or back up, since it cannot be opened without the master password. It is not safe to assume individual passwords inside it are separately protected once the file is open: USER_PASSWORD values are ordinary column data, readable to anyone who can query the CDF (which requires the master password). This is the same trust model as most database-connection managers: one master secret gates access to everything behind it.

The default master password

Every fresh install ships with the same master password, clipper8AD, documented publicly, in this guide included, which means it provides no real protection on its own. Change it on every install with SET MASTER PASSWORD; (see SET MASTER PASSWORD) before adding real connections. Treat an un-changed default password the same way you'd treat a database shipped with a default admin password never rotated.

Connections PULL AS H2 creates automatically

When PULL ... AS H2 needs to create a new local H2 database (rather than reuse an existing connection), it registers it with fixed credentials, sa / clipper8AD: not real protection, since they're identical on every install and recoverable from BroadSQL's own shipped code. They exist only because opening the file later requires some username and password. Don't treat a PULL-created H2 file as access-controlled; protect it the same way you'd protect any other file containing exported data, with filesystem permissions. See PULL.

What BroadSQL does not do

• It does not transmit connection credentials anywhere except to the database they authenticate against, over whatever protocol that database's own JDBC driver uses (BroadSQL does not add its own transport encryption on top: if you need TLS to your database, configure it the same way you would for any other JDBC client, typically via connection URL parameters).
• It does not phone home, collect usage telemetry, or contact any BroadSQL/UpAndCoding server during normal operation: see Third-party dependencies for everything bundled inside it.
• It does not encrypt the per-connection activity log or EXPORT/DUMP/PULL output files: anything written to disk by these features is plain text (or the target format's own native encoding), readable by anyone with filesystem access. See Command activity log.

Open, auditable source

The core of BroadSQL, the code that parses your commands and talks to your databases, is published separately at github.com/lico/broadsql-source, along with its full test suite. Nothing on this page needs to be taken on faith: read the code yourself, or build it and run the same tests we do.

That repository is a subset of the full project (the maintainers' internal release tooling and working documents are not included), published under the Apache License, Version 2.0. See its own README and LICENSE for the exact terms; they cover only that published excerpt, not the BroadSQL product itself (see License).

Reporting a security issue

If you find a security problem in BroadSQL, contact us directly rather than filing a public issue: see Contact.