For the consistency/security rules, I meant that any API accessible in the browser is also publicly accessible to anyone.
not quite. you still need access credentials. having an API doesn't mean that anyone can access it without permission. you protect an API the same way you protect the actual website.
Quite a lot easier to e.g. syphon data out of a system than if they just did SSR.
if the data is sent to the client, then the client ca access it either way. sure, embedding it in HTML makes it harder to parse, but that is really just security by obscurity. that's actually another reason why i prefer APIs. they make it blatantly obvious what data you are publishing. in a SSR page it is easier to let things slip through. the SSR page looks like a closed box, it gives the impression that it is possible to prevent users from entering that box and getting data out of it, but that is an illusion.
you'll have to build a proverbial Chinese wall between frontend and backend.
which is the API. small, only containing what is needed, very easy to verify that private data doesn't leak out.
Yeah, if the API design prevents this, parsing HTML is about as hard. But I've seen a lot of cases where a single request will get you _all_ the data you could ever want, a lot of it not even rendered on the frontend, no need to deal with pagination or anything. Kinda full database access as long as you have an auth token, which any logged in user has.
those are the cases that make it into the news when someone reports the insecurity of a API they found, and then gets accused for breaking into the website or database.
there are many reasons to prefer SSR over SPA, but covering up incompetence should not be one of them. designing an API is not hard.
not quite. you still need access credentials. having an API doesn't mean that anyone can access it without permission. you protect an API the same way you protect the actual website.
Quite a lot easier to e.g. syphon data out of a system than if they just did SSR.
if the data is sent to the client, then the client ca access it either way. sure, embedding it in HTML makes it harder to parse, but that is really just security by obscurity. that's actually another reason why i prefer APIs. they make it blatantly obvious what data you are publishing. in a SSR page it is easier to let things slip through. the SSR page looks like a closed box, it gives the impression that it is possible to prevent users from entering that box and getting data out of it, but that is an illusion.
you'll have to build a proverbial Chinese wall between frontend and backend.
which is the API. small, only containing what is needed, very easy to verify that private data doesn't leak out.