26 ms·

And that is how you end up with massive data leaks.

by rvr_ 6y ago

Tarq0n 6y ago
Can you provide any examples of postgREST being involved in a data leak?
- rvr_ 6y ago
  Why should I? the whole idea is error prone. I have seen, many times, in the wild, excessive data exposure thru REST APIs. Lowering the bar does not help.
  - michelpp 6y ago
    PostgREST is far more secure than most API servers. Any API server can leak data. Most API servers define their own, native, completely one-off security system that does all checks in-app and logs into the database as a superuser. The framework-du-jour is basically an insecure rooted processes by definition. PostgREST logs in with zero privileges. It then uses Postgres' native role based row-level security system to control access. Are you saying that is insecure?
    - adevx 6y ago
      PostgREST is not inherently more secure, it is as secure as your RLS policies and session mapping. It comes at a price of tight database coupling. When using a cache layer you might need to write an api level security layer anyway.
    - rvr_ 6y ago
      Do you remember the old days, when desktop apps (many written in Delphi) connected directly to the SGDB, relying on views and stored procedures? This kind of "server-client" software is still very common inside corporate LANs. Since the browser speaks a very limited set of protocols, projects like postgREST are just a bridge between frontend and storage, thus moving all needed business logic inside into the SGDB. This kind of model is hell. It's history repeating itself all over again.
      - steve-chavez 6y ago
        SGBD=RDBMS in spanish, right? What RDBMS did you use in on those times? PostgreSQL is pretty powerful these days(RLS, Extensions, FDWs, json functions, etc). I'm lead to believe that older RDBMS's didn't offer all the rich functionality we have today.
      - rishav_sharan 6y ago
        Can you elaborate why is it hell or error prone? I have used these kind of db apps in the olden days but never really heard of these issues

And that is how you end up with massive data leaks.

by rvr_ 6y ago

And that is how you end up with massive data leaks.

Tarq0n 6y ago

Can you provide any examples of postgREST being involved in a data leak?

rvr_ 6y ago
Why should I? the whole idea is error prone. I have seen, many times, in the wild, excessive data exposure thru REST APIs. Lowering the bar does not help.
- michelpp 6y ago
  PostgREST is far more secure than most API servers. Any API server can leak data. Most API servers define their own, native, completely one-off security system that does all checks in-app and logs into the database as a superuser. The framework-du-jour is basically an insecure rooted processes by definition. PostgREST logs in with zero privileges. It then uses Postgres' native role based row-level security system to control access. Are you saying that is insecure?
  - adevx 6y ago
    PostgREST is not inherently more secure, it is as secure as your RLS policies and session mapping. It comes at a price of tight database coupling. When using a cache layer you might need to write an api level security layer anyway.
  - rvr_ 6y ago
    Do you remember the old days, when desktop apps (many written in Delphi) connected directly to the SGDB, relying on views and stored procedures? This kind of "server-client" software is still very common inside corporate LANs. Since the browser speaks a very limited set of protocols, projects like postgREST are just a bridge between frontend and storage, thus moving all needed business logic inside into the SGDB. This kind of model is hell. It's history repeating itself all over again.
    - steve-chavez 6y ago
      SGBD=RDBMS in spanish, right? What RDBMS did you use in on those times? PostgreSQL is pretty powerful these days(RLS, Extensions, FDWs, json functions, etc). I'm lead to believe that older RDBMS's didn't offer all the rich functionality we have today.
    - rishav_sharan 6y ago
      Can you elaborate why is it hell or error prone? I have used these kind of db apps in the olden days but never really heard of these issues