Overview
Most web applications store their data in a database behind the backend. How the application talks to that database — safely or unsafely — is the root of some of the most serious web vulnerabilities. This lesson introduces databases in the web architecture.
Learning objectives
- Explain the role of a database in a web application.
- Describe how the backend queries a database.
- Connect unsafe query construction to injection risk.
Core concept
A database stores an application's persistent data (users, orders, content). The backend communicates with it using queries — often SQL for relational databases. The frontend never talks to the database directly; it goes through the backend, which is responsible for constructing queries safely.
The central security concern: when a query is built by mixing untrusted user input with query code, an attacker may be able to alter the query's meaning — the essence of injection.
How it works
A user action (e.g. a search) sends input to the backend, which builds a database query incorporating that input and runs it. If the backend safely separates data from code (using parameterized queries / prepared statements), user input is treated strictly as data and cannot change the query's structure. If instead it concatenates input directly into the query string, the input can break out and inject new commands. This distinction is the foundation of the SQL Injection module later.
Practical example
Consider a search that looks up products by name. Done safely, the product name is passed as a parameter — the database treats it purely as a value, so even unusual input just becomes a (fruitless) search term. Done unsafely, the name is glued directly into the query text, so specially crafted input could change what the query does. The safe approach (parameterization) is covered in depth in the SQL Injection lesson.
Cybersecurity relevance
Databases hold the crown-jewel data, so how the backend queries them is critical. Injection flaws — from unsafe mixing of input and query code — can expose or destroy entire datasets and are among the highest-impact web vulnerabilities. Additional concerns include least-privilege database accounts (the app should not use an all-powerful account) and protecting stored sensitive data. Understanding the backend-to-database link sets up injection, authorization, and data-protection topics throughout the path.
Common mistakes
- Building queries by concatenating user input, enabling injection.
- Using an over-privileged database account for the application, worsening the impact of any flaw.
- Assuming the frontend limits what reaches the database — the backend must sanitize/parameterize.
Key takeaways
- Databases store an app's persistent data; the backend (not the frontend) queries them, typically with SQL.
- Safely separating data from query code (parameterized queries) prevents input from altering a query's meaning; unsafe concatenation enables injection.
- Databases hold high-value data, so query safety, least-privilege DB accounts, and data protection are central web-security concerns.
Check your understanding
- Why does mixing untrusted user input directly into a query string create a security risk?
- Why should a web application use a least-privilege database account rather than an all-powerful one?