Looking over the list there are a number of things related to exposing too much data to the wrong people.
I do wonder how the rise of technologies such as GraphQL have impacted this over the years. It’s obviously a big problem with REST APIs as well but the way I would think about securing it is fairly well understood I think.
I don’t have the experience with GraphQL to know any better but from my brief exposure they seem like they might be particularly vulnerable to this kind of thing and I was hoping someone here might be able to tell me if that intuition is true or not.
My experience aligns with your intuition. I would go further, though, and suggest that the rise of SPA itself has exacerbated this problem (Rest or GraphQL). Unless a company has detailed security reviews, it’s very easy for client side developers to reach for an endpoint that exposes more data than they need. Because they don’t explicitly use some of that data, they forget they have exposed it.
This is certainly a protection that we’ve lost as we moved away from server rendered architecture, where no APIs are exposed and only explicitly needed data is sent to the client. Not passing judgment, but there is a higher risk profile in multiple ways for a SPA.
Especially when you have technologies like Firebase or something like that where you might be interacting with the database essentially from your front end code.
That can end up leaving a big gap between what you are visually exposing and what you’re actually exposing.
Getting authorisation right with GraphQL is no different to getting it right with REST, provided you push the checks down into your data access layer. You could do that with e.g. row-level security in Postgres or with something home-baked. The point is that centralising it below the level of the API means everything just works (and anyone adding new endpoints/resolvers doesn't have to remember to "add" authorisation checks).
4 comments
[ 3.7 ms ] story [ 15.8 ms ] threadI do wonder how the rise of technologies such as GraphQL have impacted this over the years. It’s obviously a big problem with REST APIs as well but the way I would think about securing it is fairly well understood I think.
I don’t have the experience with GraphQL to know any better but from my brief exposure they seem like they might be particularly vulnerable to this kind of thing and I was hoping someone here might be able to tell me if that intuition is true or not.
This is certainly a protection that we’ve lost as we moved away from server rendered architecture, where no APIs are exposed and only explicitly needed data is sent to the client. Not passing judgment, but there is a higher risk profile in multiple ways for a SPA.
Especially when you have technologies like Firebase or something like that where you might be interacting with the database essentially from your front end code.
That can end up leaving a big gap between what you are visually exposing and what you’re actually exposing.