OWASP’s Authentication Cheat Sheet states unequivocally:

Do NOT allow login with sensitive accounts (i.e. accounts that can be used internally within the solution such as to a back-end / middle-ware / DB) to any front-end user-interface.

(Emphasis in the original. This advice is unconditional; i.e., without regard to threat model.)

I’d like (a) some help interpreting exactly what this guidance prohibits and (b) any analysis regarding whether this prohibition is always justified or, more specifically, in my case.

I’m building a web application that uses a database to handle users and their access to their own generated/stored files. (I’m using Python Flask with SQLAlchemy.) The only personal information in the database is the user’s email address (disposable emails are encouraged). The database doesn’t even have the users’ names, much less payment info of any kind or any sensitive data. The users’ files (chess opening repertoires) are competitively sensitive, but only when linked to a player’s actual online or IRL identities. (There’s nothing secret about the chess moves in any repertoire, only that that particular player intends to play those moves, the knowledge of which would benefit a likely future opponent.)

Read literally, OWASP’s guidance would seem to prohibit any admin user accessing the database through a web interface (since, to my mind, such a web interface would be a “front-end user-interface”). I guess that would permit remote access only through some kind of SSH/Shell interface? (Web access to admin functions is very common, e.g., for any WordPress or other CMS system.)

Or should “front-end user-interface” be read only more narrowly to refer to the same front-end user interface through which non-privileged users login? If so, would it be sufficient for (a) admin credentials to not work for non-admin activities and (b) admin login would be possible only through a login URL (what Flask denotes a “route”) that is distinct from (and obscured from, i.e., random, non-guessable URL prefix) non-privileged users’ login URL?

(I see my question as entirely distinct from questions regarding whether the web server should be a separate server from the database server, because you could ask my question—whether the database server can be remotely accessed via a web interface—in either scenario.)

1 Answer 1


It suggests that any account used to login to the same applications back-end / middle-ware / DB layers not be allowed to log in to the application front end itself.

Admin credentials for the app itself would not fall under this guidance.

  • Thanks, @Rodrigo. What I’m still puzzled by… Take the case of a WordPress website (or other CMS) where admins can log into the back-end via the website interface. And less-privileged or non-privileged users would also log in through that same interface. Is that a violation of this principle? If so, if admins want to access the back-end via the web, what would be sufficient separation? For example, two different tables in the database, one for Users and one for SuperUsers? Or instead, two different databases? Aug 12, 2022 at 4:21
  • 1
    Those use cases are not affected by this OWASP principle, as those are all app users, and are not (presumably) the same logins for your DB or other middleware. The concern is, for example, that you grant the master/root account for the DB login authorization to the app itself. If that account got phished or compromised via a web application vulnerability, it would expose access to your internal DB as well. This is the use case the guidance is trying to address. Backend here refers to a backend/data tier like a DB, not the web admin "back-end" - hope that helps. Aug 12, 2022 at 15:07
  • 1
    Thanks! I was blurring over the distinction you’re making, I think. You’re distinguishing between (a) direct access to the SQL or whatever database on a database server and (b) the indirect access to the database that an admin logging in via the site (e.g., WordPress) has. A bad actor that phished the password of an admin logging in through the website could still do damage through the web-admin dashboard (more on a record-by-record basis), but perhaps not as much, I guess, as someone with direct access to the web server. Aug 12, 2022 at 18:17

You must log in to answer this question.

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