If SQL injection is picking a lock, this is entering through an unlocked door.

Not sophisticated at all, authentication on API routes is way earlier on the security checklist than SQL query sanitisation. This site is amateur work.

Not to worry, they don’t use SQL

Much much simpler, with a SQL injection at least you have to bypass the filters set, this is just submitting the changes through an API and the DB just eats it up.

SQL injection is like this: you have something you can interact with on the browser like a form containing different values.

You hit a button and that value is sent and merged into a SQL query.

Say the value is an user ID and you’re deleting an account, perhaps your own.

If the coder is incompetent the API will run this query: “DELETE FROM USERES WHERE ID = <id in form>”

Which means that if you open the developer console, change the value field for that html ID you can break that SQL line and write more SQL, or you can delete other users based on their ID.

Essentially editing a frontend input allows that input to be ran directly by the SQL engine. It’s like having full access.

So through that ID field you can inject more SQL code. There’s multiple ways to do this, sometimes the URL itself on a website uses these query parameters like "&search=something” and the “something” is injected into the SQL string.

SQL injection is baby’s first exploit, this method is like granting everyone DB access.

I’m not an expert, but it sounds comparable.