This is still over engineered. Just connect directly to the database from the client instead of having an API endpoint.
I thought that was the joke.
Does ReST mean anything anymore? It was originally a set of principles guiding the development of the HTTP 1.1 spec. Then it meant mapping CRUD to HTTP verbs so application-agnostic load balancers could work right. And now I guess it’s just HTTP+JSON?
GraphQL:
What could possibly go wrong. Little Bobby Tables would be proud.
it’s called microservice
/anal
Stop over-engineering shit, just do everything client-side like McDonald’s: https://bobdahacker.com/blog/mcdonalds-security-vulnerabilities
My friend who helped me research the OAuth vulnerabilities was let go for “security concerns from corporate”
Good old shooting the messenger.
I mean, they were an employee who was exploring security vulnerabilities with a non-employee who has a blog. I would have fired them too.
It is indeed a very risky move without a lot to gain for him personally. But I could guess McDonald’s would have forced him to ignore it and shut up about it if he disclosed this to the higher ups himself, in which case I would have gladly left myself instead.
Hilariously enough, just today I read a blog post about a service where the client interacts with the database directly - https://clickhouse.com/blog/building-a-paste-service-with-clickhouse. While it’s not your traditional OLTP database, it still kinda fits.
I knew a person that did this
Lmfao
Exposed deprecated cred-inclusion URI format, wheeeee
And the db name is short for “analysis”, of course
🤓🫠
Analytics, most likely
And the db name is short for “analysis”, of course
This person was probably a scientist (of any kind).
I work with several people who would think this is a good idea.
When they push it to prod, and our WAF goes
403on every request, then suddenly it’s my problem to “fix”.Can I just say, I love that little round gif at the end. That look so cool
Thanks :)
My home instance has some top-shelf custom emojis, so I try to use them. Janeway’s eye roll gets a lot of mileage.
Are your coworkers 12?
(one of my favorite memes)“I get why we have a WAF, but can’t you just, like, separate the good SQL injection from the bad SQL injection?” – Developers I work with 😆
I think that’s called “Heisenberg’s Uncertain SQL Injection Principle”
Unfortunately, our WAF appliances don’t have a Heisenberg compensator.
I wish I could go back to rest apis. My company is all in on graphql and it fucking sucks so much ass.
grapql in a nutshell
And OData!
It’s not that bad that you might think, the db user just need to have readonly access permissions to specific database tables.
Ofc all data in tables ofc need to be public, so more like simple public facing page, app should not have any notion of users in any way, data probably populated by some automated system, and UI just to make it easier for anonymouse users to view that data in a friendly way.
On top of that it will be a hell for the sysops as they will need to know the whole db structure and such of even a single part of db would contain non-public data, but that overall the best guy to handle security in the first place.
And because all data is totally public in the first place you could give the task of creating frontend to any junior or LLM and it will be still secure.
But in truth it is very bad idea (even it it is possible), because most likely the database connections would be reused so you could for example change current connection session timezone or other params and that ofc would nit change the data in db but still could affect other users by showing wrongly formatted or shifted data.
Most DBs have some way to reset reused connections. Postgres is one of those.
The actual problem, even with public data, is that it’s trivial to overload a database with bad queries.
CouchDB (a no-sql db, but whatever) automatically provides a REST API that’s designed to be exposed directly to clients. It even implements its own client-facing authentication system. “queries” are configured in advance from the admin side, and clients just pull the results, allowing for very efficient caching. Basically, if you RTFM enough to get a couchdb instance running, you have 90%-100% of your backend complete. You could create an entire scalable full-stack app using only client-side code… and if you’re clever with HTMX, you might even be able to do it without writing any javascript at all! (I tried once, but failed because I’m not that clever, but it’s definitely probably possible)
So TL;DR: I like couchdb, and the idea of exposing your database directly to users isn’t unprecedented. I wonder if there are any SQL databases that offer a similar thing?
Great idea. How can we submit this to all AI scrapers?
/cybersec red teamer
