Database Inference & Aggregation Simulator
Learn about database inference attacks through interactive guided scenarios. Query mock HR, medical, and financial databases using aggregation functions, discover how sensitive data can be deduced, and explore countermeasures like polyinstantiation, noise injection, and cell suppression.
Want to learn more?
Understand how inference and aggregation attacks extract sensitive data from databases.
Read the guideDatabase Inference Attack Simulator
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.
What You Can Do With It
- Query three sample databases. An HR database of nine employees (department, title, salary, years employed, with salary marked sensitive), a medical database of nine patients (age, department, diagnosis, blood type — diagnosis and blood type sensitive), and a financial database of nine accounts (account type, balance, credit score, region — balance and credit score sensitive).
- Build aggregate queries visually. Choose the aggregate function, the column, an optional
WHEREclause with an operator of=,!=,>,<,>=or<=, and an optionalGROUP BY. The generated SQL is shown so you can see what you are actually asking. - Follow three guided scenarios step by step, each with the reasoning explained after every query and a stated key lesson at the end.
- Toggle four countermeasures independently and re-run the same attack to see what changes.
- Challenge mode. Every countermeasure is enabled and you are asked to deduce a specific salary anyway, with a running count of how many queries it took.
- Query log. Every query is recorded with its outcome — success, blocked, noised or suppressed — which is itself the point: audit trails are how these attacks are detected in the real world.
The Three Guided Scenarios
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.
The Four Countermeasures, and What Each Actually Stops
| 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.
How to Use the Simulator
- Start in educational mode with all countermeasures off. Pick Scenario 1 and step through it, reading the explanation after each query.
- Re-run the same scenario with cell suppression on. Watch the final query get suppressed.
- Run Scenario 2 with cell suppression still on. It succeeds — this is the moment the concept lands.
- Turn on query restriction and run Scenario 2 again. The complementary query is now blocked with an explicit message naming the reason.
- Switch to challenge mode. All defences are up and the target is Alice Reynolds’ salary. See how few queries you need, and watch the log fill with blocked attempts — a pattern a real audit system would flag.
- Free-query the medical and financial databases to see how the same techniques transfer to diagnoses, balances and credit scores.
Why This Matters Outside an Exam
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.
Frequently Asked Questions
What is a database inference attack?
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.
How is inference different from aggregation?
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.
Why does a group size of one break everything?
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.
Is a minimum group size of 3 enough in practice?
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.
Does noise addition make data useless?
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.
What is polyinstantiation?
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.
Is any of this data real?
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.
Can I use this to attack a real database?
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.
Related Tools
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 Attack Simulator
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.
What You Can Do With It
- Query three sample databases. An HR database of nine employees (department, title, salary, years employed, with salary marked sensitive), a medical database of nine patients (age, department, diagnosis, blood type — diagnosis and blood type sensitive), and a financial database of nine accounts (account type, balance, credit score, region — balance and credit score sensitive).
- Build aggregate queries visually. Choose the aggregate function, the column, an optional
WHEREclause with an operator of=,!=,>,<,>=or<=, and an optionalGROUP BY. The generated SQL is shown so you can see what you are actually asking. - Follow three guided scenarios step by step, each with the reasoning explained after every query and a stated key lesson at the end.
- Toggle four countermeasures independently and re-run the same attack to see what changes.
- Challenge mode. Every countermeasure is enabled and you are asked to deduce a specific salary anyway, with a running count of how many queries it took.
- Query log. Every query is recorded with its outcome — success, blocked, noised or suppressed — which is itself the point: audit trails are how these attacks are detected in the real world.
The Three Guided Scenarios
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.
The Four Countermeasures, and What Each Actually Stops
| 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.
How to Use the Simulator
- Start in educational mode with all countermeasures off. Pick Scenario 1 and step through it, reading the explanation after each query.
- Re-run the same scenario with cell suppression on. Watch the final query get suppressed.
- Run Scenario 2 with cell suppression still on. It succeeds — this is the moment the concept lands.
- Turn on query restriction and run Scenario 2 again. The complementary query is now blocked with an explicit message naming the reason.
- Switch to challenge mode. All defences are up and the target is Alice Reynolds’ salary. See how few queries you need, and watch the log fill with blocked attempts — a pattern a real audit system would flag.
- Free-query the medical and financial databases to see how the same techniques transfer to diagnoses, balances and credit scores.
Why This Matters Outside an Exam
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.
Frequently Asked Questions
What is a database inference attack?
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.
How is inference different from aggregation?
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.
Why does a group size of one break everything?
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.
Is a minimum group size of 3 enough in practice?
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.
Does noise addition make data useless?
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.
What is polyinstantiation?
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.
Is any of this data real?
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.
Can I use this to attack a real database?
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.
Related Tools
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.
Protecting Sensitive Database Data?
Our team implements database security controls, access logging, and inference prevention.
What Is Database Inference
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.
How Database Inference Attacks Work
Inference attacks exploit the mathematical relationship between aggregate query results and individual records:
Common Inference Techniques
| 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 |
Example Attack Scenario
- Attacker queries: "How many employees in Engineering earn over $200K?" → Result: 1
- Attacker knows there are 3 engineers: Alice, Bob, Carol
- Attacker queries: "How many employees named Alice or Bob in Engineering earn over $200K?" → Result: 0
- By elimination: Carol earns over $200K — sensitive information inferred without direct access
Common Use Cases
- Privacy impact assessment: Test whether your database's query interface leaks personally identifiable information through aggregate queries
- Access control design: Determine what query restrictions are needed to prevent inference on sensitive columns
- HIPAA/GDPR compliance: Demonstrate that de-identified or aggregate health and personal data cannot be re-identified through query combinations
- Data warehouse security: Evaluate whether analytical dashboards expose underlying individual records
- Security training: Teach developers and data analysts how seemingly safe queries can leak confidential information
Defense Strategies
- Query restriction — Suppress results from aggregate queries where the group size falls below a minimum threshold (typically k=5 or k=11). This prevents queries from isolating individuals.
- Differential privacy — Add calibrated random noise to query results. The noise is large enough to protect individual records but small enough to preserve statistical accuracy for legitimate analysis.
- Query auditing — Log and analyze all queries to detect patterns consistent with inference attacks. Flag sequences of queries that progressively narrow result sets.
- Cell suppression — In statistical reports, suppress cells with too few contributors and also suppress complementary cells that would allow back-calculation.
- Data generalization — Replace precise values with ranges (e.g., salary bands instead of exact figures) and use k-anonymity to ensure each record is indistinguishable from at least k-1 others.
Frequently Asked Questions
Common questions about the Database Inference & Aggregation Simulator
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.
Explore More Tools
Continue with these related tools
ℹ️ Disclaimer
This tool is provided for informational and educational purposes only. All processing happens entirely in your browser - no data is sent to or stored on our servers. While we strive for accuracy, we make no warranties about the completeness or reliability of results. Use at your own discretion.