Run aggregate queries on sample databases and see how SUM, AVG and COUNT leak individual records. Toggle cell suppression, noise and query restriction.
An interactive sandbox for one of the least intuitive ideas in data security: a database can leak individual records without ever returning one. Run aggregate queries — COUNT, SUM, AVG, MIN, MAX — against three realistic sample databases, watch how carefully chosen aggregates reveal specific people’s salaries and diagnoses, then switch on the standard countermeasures and see exactly which attacks they stop and which they do not.
This is a teaching tool, aimed at CISSP and Security+ candidates working through the inference and aggregation material, at data engineers designing analytics access, and at privacy and compliance staff who need to explain to a stakeholder why “we only expose aggregates” is not by itself a control. It runs entirely in your browser against fabricated data — there is no real database behind it and no query you run leaves your machine.
WHERE clause with an operator of =, !=, >, <, >= or <=, and an optional GROUP BY. The generated SQL is shown so you can see what you are actually asking.Scenario 1 — deduce the CEO’s salary. Count the Executive department: three people, too many to isolate. Count employees with the title CEO: one. Now ask for AVG(salary) WHERE title='CEO'. Because the group has exactly one member, the average is the individual value: $350,000. This is the fundamental inference vulnerability — any aggregate over a group of one is a disclosure of that one record.
Scenario 2 — the subtraction attack. Ask for SUM(salary) across all nine employees: $1,398,000. Then ask for the same sum WHERE name != 'Alice Reynolds': $1,048,000. Each query aggregates many records and looks entirely safe in isolation. Subtract them and you have $350,000 — Alice’s exact salary. Two harmless queries, one complete disclosure. This is why per-query size thresholds are insufficient: the attack lives in the relationship between queries, not in any single one.
Scenario 3 — medical inference with external knowledge. Two patients are in Oncology. Only one is over 40. The minimum age in Oncology is 38. Cross-reference those three aggregates with a public hospital directory listing names, ages and departments, and you have identified which named individual has which record — without the database ever returning a diagnosis. This is the re-identification problem that makes HIPAA’s safe-harbour de-identification rules as strict as they are.
| Countermeasure | How it is implemented here | Stops | Does not stop |
|---|---|---|---|
| Cell suppression | Any result whose group contains fewer than 3 records is replaced with [SUPPRESSED], including per-group in a GROUP BY | Scenario 1 — the group-of-one disclosure | Subtraction attacks, which never query a small group |
| Noise addition | Every non-COUNT aggregate is perturbed by a random 5–15% in either direction | Exact-value recovery; the answer is now approximate | Repeated querying — the noise is re-rolled each time, so averaging many runs converges back on the truth |
| Query restriction | Blocks any WHERE clause matching fewer than 3 records, and blocks a != query whose excluded set is smaller than 3 | Both Scenario 1 and Scenario 2, including the complementary-query form | Attacks assembled from several individually legitimate queries and outside knowledge |
| Polyinstantiation | Queries against a sensitive column return a clearance-level value (85% of the real figure) alongside a note of the true value | Disclosure of the true value to a lower clearance | Anything relying on relative comparisons rather than absolute values |
Working through the combinations is the actual lesson. Cell suppression alone feels like a solution until Scenario 2 walks straight through it. Noise addition feels rigorous until you realise the log shows you ran the same query eleven times. Query restriction is the strongest of the four here, and it is also the one that most annoys legitimate analysts — which is the real trade-off every data platform has to make.
The same mechanics govern real systems. A BI dashboard that lets analysts filter freely and shows aggregates is a query interface. An HR analytics tool that reports average compensation by department, level and location will eventually produce a cell with one person in it. A public health dataset that publishes case counts by postcode, age band and outcome is one cross-tabulation away from identifying individuals. Statistical agencies have dealt with this for decades using suppression thresholds, rounding, cell swapping and, more recently, formal differential privacy — which is essentially noise addition with a rigorous accounting of how much total information a series of queries has leaked, the piece that the naive noise implementation demonstrated here is missing.
For a deeper written treatment of the attack classes and mitigations, see our guide to database inference and aggregation attacks.
Deriving information you are not authorised to see from information you are authorised to see. In a database context that usually means reconstructing individual records from permitted aggregate queries, often combined with knowledge from outside the database.
Aggregation is the risk that combining many individually harmless facts produces a sensitive whole — a directory listing plus a floor plan plus a shift roster. Inference is deducing a specific unauthorised fact from authorised ones. Certification exams test both, and they frequently appear together, as Scenario 3 shows.
Because every aggregate function collapses to the identity on a single row. AVG, SUM, MIN and MAX over one record all return that record’s value, and COUNT tells the attacker the group size is one so they know the others are exact.
No. Three is the threshold used here because it makes the demonstration clear, but real disclosure-control regimes often require 5, 10 or more, and a threshold alone never defends against complementary queries. Query auditing across a session is required as well.
It is a trade-off dial, not a switch. A 5–15% perturbation is invisible for trend analysis and fatal for reconciliation. The deeper problem shown here is that naive noise is defeated by repetition; differential privacy addresses this by budgeting the total privacy loss across all queries a user makes.
Storing several versions of the same record at different classification levels, so a lower-clearance query gets a plausible cover value rather than a refusal. It defeats the inference you get from a rejection — being told “access denied” itself confirms that something sensitive exists there.
No. All three databases are fabricated fixtures of nine records each, held in the browser. No real personal data is involved and nothing is transmitted anywhere.
No — it queries only its own built-in sample data and has no connectivity of any kind. Its purpose is to make the failure modes intuitive so you can design better controls.
For the policy side of the same problem, the data classification architect helps decide which columns count as sensitive in the first place, the GDPR role and retention mapper covers lawful basis and retention, and the HIPAA quick assessment is the natural follow-up when the data in question is clinical. For generating safe test fixtures instead of using production extracts, see the mock data generator.
Database inference is a security threat in which an attacker derives sensitive information from seemingly innocuous query results. Even when direct access to confidential data is restricted, the combination of permitted queries, aggregate functions, and metadata can reveal protected information. This is a particular concern for statistical databases, data warehouses, and systems that provide analytical query access to multiple users with different privilege levels.
Unlike SQL injection, which exploits input validation flaws, inference attacks exploit the legitimate functionality of a database. An attacker uses authorized queries — counting, averaging, filtering — to narrow down results until they can deduce specific records or values that they should not be able to access.
Inference attacks exploit the mathematical relationship between aggregate query results and individual records:
| Technique | Method | Example |
|---|---|---|
| Direct inference | Query results directly reveal sensitive data | "SELECT AVG(salary) WHERE department = 'CEO Office'" returns one person's salary |
| Indirect inference | Combining multiple queries isolates individuals | Two queries with overlapping filters differ by one record |
| Tracker attacks | Crafting complementary queries that sum to the full database | Query for condition C plus query for NOT C equals all records |
| Homogeneity attacks | All records in a group share the same sensitive value | Every person in a filtered result has the same diagnosis |
| Background knowledge | External data combined with query results | Knowing someone is in a specific department plus aggregate data |
An inference attack uses legitimate queries on non-sensitive data to deduce sensitive information. For example, querying the average salary of a department with only one person reveals that person's exact salary. Even when direct access is denied, aggregation functions (COUNT, AVG, SUM) can leak individual data points.
When a query returns aggregate results for a small group, individual values can be deduced. If you know the sum of salaries for 5 people and the sum for 4 of them, simple subtraction reveals the 5th person's salary. This simulator demonstrates these attacks with guided scenarios on mock databases.
Polyinstantiation creates multiple instances of the same data at different classification levels. A Top Secret user sees the real data, while a Secret user sees a plausible but different version. This prevents inference attacks by eliminating the ability to detect that data exists at a higher classification level.
Key countermeasures include: cell suppression (hiding values in small groups), noise injection (adding random perturbation to query results), query restriction (limiting queries that return small result sets), polyinstantiation (multiple data versions by clearance), and differential privacy (mathematical guarantees against inference).
Database security is covered in CISSP Domain 8: Software Development Security. Key topics include database inference and aggregation attacks, polyinstantiation, views for access control, database encryption, and the role of the DBMS in enforcing security policies. Understanding these attacks is essential for the CISSP exam.
Format and beautify SQL queries with proper indentation, keyword capitalization, and line breaks. Supports MySQL, PostgreSQL, SQL Server, Oracle, and more.
Generate CONVERT() and CAST() syntax for MySQL, PostgreSQL, SQL Server, Oracle, and SQLite with dialect-specific type mappings.
Design comprehensive data classification policies with government (TS/S/C/U) or commercial (Restricted/Confidential/Internal/Public) schemas. Define handling rules for storage, transmission, disposal, and access with compliance overlays for HIPAA, PCI-DSS, GDPR, and CMMC.