4 ms·

> it's the difference between a $200m raise with a bunch of untested API endpoints and a $10m raise with them. I'm tired of companies with API endpoints that l

> it's the difference between a $200m raise with a bunch of untested API endpoints and a $10m raise with them. I'm tired of companies with API endpoints that leak data like a sieve. This is why companies need some skin in the privacy game. Purposefully neglecting the safety of user data for "speed" like this should have your company taken away from you. Why can't adults stop behaving like toddlers?

Aeolun 4y ago
> Why can't adults stop behaving like toddlers? It certainly seems like a very successful strategy.
djsweet 4y ago
> > it's the difference between a $200m raise with a bunch of untested API endpoints and a $10m raise with them. > I'm tired of companies with API endpoints that leak data like a sieve. This is why companies need some skin in the privacy game. There is a world of difference between “untested” and “insecure” API endpoints. What seems to have been cut in the example isn’t a permissions model, but some form of automated integration testing. I’ve seen horribly insecure APIs with 100% code coverage, and I’ve personally burned myself on untested API endpoints where the privacy implementation was _too_ restrictive for what my customers were trying to do.
- deleted 4y ago
  [deleted]
- 3pt14159 4y ago
  Ostensibly based on what I said, yes. But in reality, he was right that untested meant partially insecure. There are real costs to tech debt. But it's hard to argue against a giant raise.
jacob_rezi 4y ago
two of our competitors have poor practice around endpoints that have opened their entire user database. What should we do?
- akiselev 4y ago
  Talk to your lawyers.
- greggsy 4y ago
  CYA by making sure you’re not making the same mistakes. Don’t try to be clever by exposing them. Tell your clients that you apply best (/better) practice.
- yourapostasy 4y ago
  These are called kill points in sales. For this kind of kill point however, you better make sure not just your own endpoints have cleanly passed scrutiny, but your entire modeling and process around them doesn’t produce insecure endpoints. Otherwise it is best not to let your sales team use such a kill point.
- jjice 4y ago
  Tangential, but I always wondered why people don't have a separate class/struct/whatever that's actually used to send out. Might be overkill, but having a separate model to represent incoming request, out going requests, and the actual domain model makes me feel a bit more secure as to what's being sent out. It requires more work to update (adding fields to the outgoing models), but gives a bit of piece of mind.
  - deleted 4y ago
    [deleted]
  - bcrosby95 4y ago
    We do this where I work. It's a lot of extra data types, but they're all extremely simple and better safe than sorry. As a rule, we don't send or receive actual domain objects in our APIs. It doesn't matter if they're currently "safe" - they might not be in the future.

Aeolun 4y ago

> Why can't adults stop behaving like toddlers? It certainly seems like a very successful strategy.

djsweet 4y ago

> > it's the difference between a $200m raise with a bunch of untested API endpoints and a $10m raise with them. > I'm tired of companies with API endpoints that leak data like a sieve. This is why companies need some skin in the privacy game. There is a world of difference between “untested” and “insecure” API endpoints. What seems to have been cut in the example isn’t a permissions model, but some form of automated integration testing. I’ve seen horribly insecure APIs with 100% code coverage, and I’ve personally burned myself on untested API endpoints where the privacy implementation was _too_ restrictive for what my customers were trying to do.

deleted 4y ago
[deleted]
3pt14159 4y ago
Ostensibly based on what I said, yes. But in reality, he was right that untested meant partially insecure. There are real costs to tech debt. But it's hard to argue against a giant raise.

jacob_rezi 4y ago

two of our competitors have poor practice around endpoints that have opened their entire user database. What should we do?

akiselev 4y ago
Talk to your lawyers.
greggsy 4y ago
CYA by making sure you’re not making the same mistakes. Don’t try to be clever by exposing them. Tell your clients that you apply best (/better) practice.
yourapostasy 4y ago
These are called kill points in sales. For this kind of kill point however, you better make sure not just your own endpoints have cleanly passed scrutiny, but your entire modeling and process around them doesn’t produce insecure endpoints. Otherwise it is best not to let your sales team use such a kill point.
jjice 4y ago
Tangential, but I always wondered why people don't have a separate class/struct/whatever that's actually used to send out. Might be overkill, but having a separate model to represent incoming request, out going requests, and the actual domain model makes me feel a bit more secure as to what's being sent out. It requires more work to update (adding fields to the outgoing models), but gives a bit of piece of mind.
- deleted 4y ago
  [deleted]
- bcrosby95 4y ago
  We do this where I work. It's a lot of extra data types, but they're all extremely simple and better safe than sorry. As a rule, we don't send or receive actual domain objects in our APIs. It doesn't matter if they're currently "safe" - they might not be in the future.