The applications you use every day store their data in a database, but hardly anyone allows the screen in your hand to communicate directly with it. There is always an intermediary layer between the two, usually in the form of an API. This layer is not just an architectural habit. It is where three security barriers are installed.
Two often confused concepts: layer and tier
Microsoft's architecture documentation distinguishes between the two. A layer is logical, while a tier is physical. A common three-tier application consists of a presentation tier, an optional middle tier, and a database tier. In a closed layer model, a layer may only call the layer directly below it. This means the screen does not touch the database; it requests to the API, and only the API may query the database.
Microsoft is also honest about the costs: a middle tier that merely forwards CRUD operations adds latency and complexity without meaningful value. So, the intermediary is not an automatic blessing. Its value lies in the following three barriers.
First barrier: network
The OWASP database security guidelines state that connections from thick clients directly to the database should never be made. The database should reside in a separate internal network segment, isolated from the application server, and accessible only by as few machines as possible. If the mobile screen or browser holds the database address and password, every copy of the application becomes a gateway.
Second barrier: least privilege
The account used by the application should not be of the administrator type. The same guidelines state that most applications only need SELECT, UPDATE, and DELETE permissions, and that account should not be the database owner. One application, one account, and development, UAT, and production environments should use separate databases and accounts. Default accounts like root, sa, or SYS should not be used.
Database passwords should also not be hardcoded in the source code. Store them in configuration files outside the web directory, readable only by relevant users, and not included in version control.
Third barrier: queries not constructed from raw input
In the API, user input should not be appended to SQL command text. The OWASP Cheat Sheet ranks its defenses: prepared statements (parameterized queries) as the first choice, properly constructed stored procedures as the second choice, followed by whitelist validation for parts that cannot be parameterized, such as table names, column names, or sort orders. Escaping input is highly discouraged due to its fragility and variability across databases.
Two important notes. Stored procedures are not automatically safe: the 2021 edition of OWASP Top 10 notes they can still be vulnerable if they concatenate queries with data or execute harmful data through EXECUTE IMMEDIATE or exec(). Validation is also not a substitute: data that passes validation is not necessarily safe to concatenate into query text.
The scale is real. In that 2021 edition, the injection category ranked third, with 94 percent of applications tested for injection forms, an average incidence rate of 3.37 percent, and 33 mapped CWEs.
Summary you can scan
| Barrier | Checked | Reference |
|---|---|---|
| Network | Database accessible only from the application server | OWASP Database Security |
| Access | Accounts without admin rights, one account per application | OWASP Database Security |
| Query | Parameterized, not text concatenation | OWASP SQL Injection Prevention |
| Access | Password outside code and outside web directory | OWASP Database Security |
How to use it
When assessing your own applications or those created by AI, ask four questions: can the database address be accessed externally, what account is used by the application and what are its permissions, are queries constructed with parameters, and where is the database password stored? A "don't know" answer to any of these is enough to warrant further investigation.
If you prefer to see the explanation directly, there is a short clip on why applications do not access databases directly. For the data access side in AI-generated applications, also see discussion on access rights and open data.