Database, Data-Layer and Query-Engine Security — DedSec Project

Database security is broader than SQL injection. It includes identity, query construction, stored logic, tenancy, replication, backups, search engines, caching, encryption, and data lifecycle. This module teaches how to reason from a data asset to every component that can read or mutate it.

Learning objectives

By the end of this module you should be able to:

• Explain Query construction and connect it to a concrete trust boundary or security invariant.
• Explain Database identity and connect it to a concrete trust boundary or security invariant.
• Explain Row and tenant isolation and connect it to a concrete trust boundary or security invariant.
• Explain Stored logic and triggers and connect it to a concrete trust boundary or security invariant.
• Explain NoSQL and search engines and connect it to a concrete trust boundary or security invariant.
• Explain Replication and backups and connect it to a concrete trust boundary or security invariant.

Deep concepts

1. Query construction

Parameterized queries separate code from data for supported values, but dynamic identifiers, sort expressions, filters, and stored procedures still require allowlisting and careful composition.

2. Database identity

Applications should use narrowly scoped service identities rather than owner/admin accounts. Distinguish schema migration privileges, runtime read/write privileges, analytics access, backup access, and emergency administration.

3. Row and tenant isolation

Multi-tenant systems need authorization at every path that reaches tenant data. Row-level security can add defense in depth, but application context, connection pooling, background jobs, exports, and caches must preserve tenant identity correctly.

4. Stored logic and triggers

Triggers, procedures, functions, extensions, and scheduled jobs execute inside a privileged data plane. Review ownership, definer/invoker behavior, search paths, extension provenance, and change control.

5. NoSQL and search engines

Document stores, key-value systems, and search engines have their own query languages and authorization models. Treat user-controlled operators, field selection, scriptable queries, and administrative APIs as distinct attack surfaces.

6. Replication and backups

Replicas, WAL/binlog streams, snapshots, exports, and backups are copies of sensitive data. Encryption, access control, retention, deletion, and restoration testing must include them.

7. Encryption boundaries

At-rest encryption protects media and some snapshot scenarios but does not stop an authorized database process from reading plaintext. Field-level/application-layer encryption changes key management and query capabilities and should be used intentionally.

8. Audit and anomaly detection

High-value events include privilege changes, schema changes, mass reads, unusual export jobs, authentication anomalies, failed authorization, and access from unexpected application identities.

Authorized exercises

Exercise 1 — Build a localhost SQLite or PostgreSQL toy application with separate migration and runtime roles; document which statements each role should be able to execute

Build a localhost SQLite or PostgreSQL toy application with separate migration and runtime roles; document which statements each role should be able to execute.

Exercise 2 — Create a tenant-isolation test matrix that covers API calls, background jobs, exports, caching, and administrative tools

Create a tenant-isolation test matrix that covers API calls, background jobs, exports, caching, and administrative tools.

Exercise 3 — Take a harmless sample backup, restore it into an isolated lab, and verify the restore procedure includes permissions and secrets—not just data files

Take a harmless sample backup, restore it into an isolated lab, and verify the restore procedure includes permissions and secrets—not just data files.

Knowledge checks

1. Explain the most important trust boundary in Database, Data-Layer and Query-Engine Security without naming a security tool.
2. Give one example where cryptographic or authentication success still does not imply authorization success.
3. Describe one stale-state or replay condition relevant to this module.
4. Identify one telemetry source that can support a strong conclusion and one blind spot it still leaves.
5. Explain how you would turn a discovered weakness into a regression test rather than a one-time finding.

Guided study workflow