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?

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.)

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.)