Temporary expirable sessions like we have today could be one way. Generate a temporary session (DB creds) for an authenticated user.

Maybe in the browser context it would reduce the security risk.

However that db backend is still listening for logins, it does not know who the client is.

What happens today imho is that you have access to pieces of the data tables not the whole database at once to run queries at will.

When you fill out an html form or click a button that runs business logic code which might run sql queries based on a token/id you passed.

That token/id does not have access to the whole database.

Temporary database wide sessions are still a risk in the browser context.

For public data I am inclined to agree with the parent.

You could just pass a single auth token to the database if it supported it for public data only and fetch it that way. Kinda like a bearer token, etc...

Therefore having direct access to the database from the client side only for public data.

This would be very beneficial to the web as a whole as a lot of the data is public data.

Then the separation of privilege/access has to happen directly at the database level which is totally possible.

Would be a nice addition to the web to treat public data differently.

At the database table level, each field could have the following properties which processed together would decide the level of access for that piece of data stored.

data_access: private|public data_scope: single|composite data_exempt: age|gender|otherpiifield

Somewhat protecting PII by not allowing querries which would infringe PII rules when selecting multiple sensitive fields.