Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
One simple answer: never trust user input (!) ... no matter if the user is an enduser, a browser, a backend system or a script kiddo with curl in some bash script.
Even if it were the responsibility of your team to prevent this issue the api have to check duplicates anyways when this is a constraint. -
@bosi Sadly, I feel that is too complex a notion to impart upon them, judging from our interactions up to this point. But yeah, that's why we raised the issue with them in the first place. Of course we'll do validation where prudent, but an API should never expect input to always be correct.
-
@botimoo Holy shit... that client's team should be purged by the use of napalm.
No wonder so many web applications are insecure af. -
They are right that this is indeed a separation of concern issue.
They are the source of truth regarding the data (store the data not just to cache/process in flight). It's their concern is correct not yours.
Hey I'm not telling you anything new but it is an answer you can give them incompetent bastards. -
@devdevdev29
Yep, validation and security aren't a separable concern. A system is as secure as its weakest link
when your code is a mess but everything work out in the end
When you keep getting +1s on a rant you posted a month ago.
Go big or go home.
Ok, so our team is responsible for writing an app that consumes an API written by the client's team (I refuse to call it a "REST" API, despite their claims). On one of the clarification meetings we are discussing an endpoint that accepts a (logically) unique field multiple times, even though an entity is already registered in the system with that unique identifier. Our proposal would be that this API of theirs should not happily accept duplicates as many times as there are bits on a 4TB hard drive, rather it should signal an error.
The response we got is this: Due to the Separation of Concerns principle they thought that it should be our app's responsibility to not send a request if an entity with said field is already in the system. Thus there's no need for the backend to validate this.
I didn't hear the next part, because I had to collect my headphones from the other side of the room where they were flung in rage.
rant
soc
api
rest