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.

  • 3
    I feel myself sliding deeper into my chair.
  • 4
    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.
  • 5
    @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.
  • 4
    @botimoo Holy shit... that client's team should be purged by the use of napalm.
    No wonder so many web applications are insecure af.
  • 3
    Well... thay ain't wrong then!

    Unreleated, any security implemented there at all? in theory, how much is thier data worth, if sold on the dark web?
  • 3
    That's gotta be a silly excuse to not sound incompetent...
  • 3
    "separation of concerns"? How the fuck are they defining that? That is back end business logic. It should be in back end.
  • 3
    Pretty sure, that is not of "separation of concern" works.
  • 2
    Blah blah it's RESTful api with a HATEOAS blah blah something (it is none of those things) management speak
  • 0
    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.
  • 2
    Yep, validation and security aren't a separable concern. A system is as secure as its weakest link
Add Comment