Regarding the following OWASP Vulnerabilities:

Can these be solved by using a database that supports Row Level Security and by creating real user accounts in the database for each user and having them login to the database as themselves (via the web server)?

Any issues in this approach to be aware of (other than it killing connection pooling)?


One obviously needs some sort of record access control. How is moving record access control from the web layer to the database layer worse, when it's more centralized? (Databases tend to live longer than applications, and databases sometimes have more than one application.)

User authentication (storage) happens in a different system.

Users are not be superusers and would have the minimum required privileges (by that I mean they can't run command shells in SQL or other silliness).

Users would not have direct db access, only access through a web application.

Would use hierarchical roles.

Would still use parameterized queries, however not all queries are parameterizable, developers make mistakes, and systems like Wordpress have shown that plugins can get you.

2 Answers 2


Not effectively, no. You're always going to have cases where row-level security can't properly emulate the business processes. You'd also need to have a lot of "general purpose" accounts for things like user signup. The whole thing would be convoluted, difficult to maintain, and largely ineffective.

Keep in mind, also, that SQL injection potentially does not only affect the data, but also the database. Special commands (like xp_cmdshell in TSQL, debug segfault in Redis) have all sorts of secondary impacts outside that of row data.

Regardless, SQL injection is largely a solved problem, so it's really not worth creating inferior solutions that are much more complex and costly.

  • Thanks for your answer. How is managing many users in the db more difficult to maintain than in an application? Users obviously wouldn't be given root db accounts, so I'm not sure how they could execute those types of functions. Parameterized queries are great, but they don't work when you need dynamic identifiers. Mar 22, 2015 at 23:09
  • @NeilMcGuigan Well, for a start, you need a mechanism to provision those accounts. Which means your provisioning user needs the ability to create new users and set their privileges - not ideal. What situation are you running into with "dynamic identifiers"? Every time I've heard that problem, it's been a use-case for a non-relational database (e.g. Redis / MongoDb) or a misunderstanding of constraints / normal form.
    – Polynomial
    Mar 23, 2015 at 9:28

No, because SQL Injection and Insecure Direct Object References includes the case of 'ability to run SQL that the user has access to but the application was designed to not allow'. Your method will limit the ability to get at stuff outside their permissions, but in most cases that includes things that aren't intended to be open, as well as system information which is usually accessible by design.

What can help is the use of stored procedures instead of application-side code, but that's not common because it makes the overall application more static and fragile.

  • I see your point about the system information. Mar 22, 2015 at 23:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .