Code review misses it
The missing filter is an absence, and absences are hard to see in a diff.
- WHERE o.tenant_id = ? AND o.status = ? + WHERE o.status = ?
QueryFence0.1.0 is in preparation
Catch tenant leaks in your SQL before production does.
QueryFence checks every SQL statement your integration tests send to the database, and fails the build on the one that forgets tenant_id. Open source, for the JVM.
~/shop · ./mvnw test
$ ./mvnw test
✓ OrderServiceTest#createsOrder · 3 statements
✓ OrderServiceTest#paysInvoice · 5 statements
✓ CustomerServiceTest#archives · 2 statements
✓ OrderServiceTest#listsPendingOrders · 1 statement
QueryFence: 1 violation (mode FAIL)
[tenant-isolation] require-predicate
table : purchase_order (alias o)
problem : no predicate on o.tenant_id
sql : SELECT o.id, o.total FROM purchase_order o WHERE o.status = ?
origin : OrderRepository#findByStatus (OrderRepository.java:42)
BUILD FAILURE · the leak never reaches production
Works with the stack you already run
The problem
Why tenant leaks slip through
Tests stay green
Fixtures usually hold one tenant, so "all orders" and "this tenant's orders" return the same rows.
✓ OrderServiceTest 62 passed BUILD SUCCESS
Production leaks
Customer A opens a page and sees customer B's orders.
tenant order total acme #10231 1,280 globex #88412 940
Simulation
Watch a leak get caught
Filtered by tenantMissing tenant filterSimulation
- 01Tests run as usual
- 02Every SQL statement is captured
- 03Checked against your policy
- 04The leak fails the build
How it works
Three steps, no test code to change
pom.xml
<dependency> <groupId>com.steelreed</groupId> <artifactId>queryfence-spring-test</artifactId> <version>0.1.0</version> <scope>test</scope> </dependency>
version: 1 mode: FAIL # or REPORT while you adopt it onUnparseable: FAIL rules: - id: tenant-isolation type: require-predicate column: tenant_id tables: [purchase_order, order_item, invoice] - id: no-unbounded-update type: update-without-where
$ ./mvnw test QueryFence: 1 violation (mode FAIL) [tenant-isolation] MISSING_PREDICATE table : purchase_order (alias o) sql : SELECT o.id, o.total FROM purchase_order o WHERE o.status = ? origin : OrderRepository#findByStatus (OrderRepository.java:42) Full report: target/queryfence/report.json
Rules
What it catches
A query with no tenant filter
SELECT * FROM invoice WHERE number = ?
A filter that an OR cancels out
WHERE o.tenant_id = ?
OR o.status = 'OPEN'A join that leaves one table open
FROM purchase_order o JOIN order_item i ON i.order_id = o.id WHERE o.tenant_id = ?
A lookup by id alone
SELECT * FROM customer
WHERE id = ? -- findByIdAn UPDATE or DELETE with no WHERE
UPDATE customer SET status = 'ARCHIVED'
An INSERT that skips the tenant
INSERT INTO audit_log (action, at) VALUES (?, ?)
SQL it cannot parse is reported too, never trusted. All rules →
Compatibility
Wherever your SQL comes from
Data access it sees
- JPA / Hibernatederived queries, JPQL, Pageable count queries
- MyBatisthe statement each set of dynamic arguments produced
- jOOQthe SQL it renders
- JdbcTemplateand plain JDBC
- Native SQLanything behind a DataSource
Tested on every pull request
- MySQL 8.4Testcontainers
- PostgreSQL 17Testcontainers
- JUnit5.10 → 6.1
- Spring Boot3.3 → 4.1
- Java17 · 21 · 25
Compared
Enforce at runtime, verify in tests
QueryFence does not replace these tools. It checks that they are doing their job.
| What it does | Where it works | What it misses | |
|---|---|---|---|
Hibernate @TenantId | Adds the tenant condition to entity queries at runtime | Hibernate entity queries | Native SQL, JdbcTemplate, MyBatis, jOOQ, a disabled filter |
| MyBatis-Plus tenant interceptor | Rewrites SQL at runtime | MyBatis-Plus | Other data-access code, tables on its ignore list |
| Postgres RLS | The database refuses other tenants' rows | Postgres | Other databases, roles that bypass RLS, a wrong session tenant |
| QueryFence | Checks every executed statement against a policy and fails the build | Any JDBC DataSource | Runtime protection, SQL your tests never run |
Status
Measured, not promised
Run against a realistic multi-tenant app it was not written for
75SQL statements checked
15real leaks found
205golden test cases
4false positives, published
QueryFenceApache-2.0 · Java 17+
0.1.0 in preparation
In 0.1
- Tenant filter, UPDATE and DELETE rules
- JUnit 5 extension and Spring Boot test support
- FAIL and REPORT modes
- Suppressions that require a reason
- Console summary and report.json
Not yet
- Blocking SQL at runtime
- Checking parameter values
- Baseline file, HTML report
FAQ
Questions
No. It watches statements through a DataSource proxy and passes them to the driver unchanged.
No. The dependency is test scope, there is no annotation to add, and suppressions live in the policy file.
A primary key is not a tenant filter: ids can be guessed, and where id = ? happily returns another tenant's row. Use findByIdAndTenantId, or map the tenant with Hibernate @TenantId.
Each distinct SQL string is parsed once and cached. The integration suite checks tens of statements per test with no measurable difference.
Not in 0.1. The engine has no JDBC or test dependencies, which keeps a runtime mode possible later, but nothing ships for it yet.
Start in REPORT mode, read the report, fix or suppress with a reason, then switch to FAIL. The adoption guide walks through it in about an hour.