4 ms·

Opening up an API like this is ripe for abuse, so taking care makes sense. Bad actors translate directly to lost money. A real method of securing APIs would be

Opening up an API like this is ripe for abuse, so taking care makes sense. Bad actors translate directly to lost money. A real method of securing APIs would be a godsend, but in current tech it's just not possible. This is the one place where mediocre security-by-obscurity is your only choice =(

KekDemaga 9y ago
"2,147,483,647 large coffees? I'd better get to work." - some poor Starbucks employee
- Jonovono 9y ago
  lol. Reminds me of high school. Constructing a green roof garden. We have the genius (see stupid) idea to go order 20 large waters from McDonalds. They just tell us to drive forward and park. Sure enough, not long later, they bring us 20 large waters!
  - smt88 9y ago
    An interaction that cost McDonald's under $2 and is something you won't forget and will actually tell others about. Sounds like they got their money's worth.
- sashk 9y ago
  This reminded me about call to Starbucks during the iPhone announcement in 2007 -- https://youtu.be/bd6dQmN-mPw?t=34s https://youtu.be/bd6dQmN-mPw?t=34s
_pmf_ 9y ago
> A real method of securing APIs would be a godsend, but in current tech it's just not possible. This is the one place where mediocre security-by-obscurity is your only choice It's magically possible when tying it to a payment processor, though.
IshKebab 9y ago
What abuse would it be ripe for exactly? I assume the only thing they were trying to prevent is third party apps.
- bpicolo 9y ago
  Say a third party app orders the wrong coffee, or orders too much stuff, etc. There's a real business risk because they have to shell out physical capital to make coffee. I might be slightly off because thinking about it the app probably requires up-front payment. But either way, fully open APIs can cause problems if they're more meant for internal processes
- prawks 9y ago
  One funny (ab)use case that may not be immediately obvious: any public API that accepts payment for goods via credit card will sooner or later attempt to be used by carders to test purchased/stolen card lists for validity.
  - lsaferite 9y ago
    So? You mitigate this on the server since you can never trust the client.
sowbug 9y ago
You can get pretty far with a secure element. Server challenges with signed payload of nonce + current timestamp, and client verifies it and then re-signs the payload. For something like a third-party coffee-ordering app, the economics of the usual attacks don't scale (either physically tearing apart the chip or exploiting a vulnerability in the first-party app).

KekDemaga 9y ago

"2,147,483,647 large coffees? I'd better get to work." - some poor Starbucks employee

Jonovono 9y ago
lol. Reminds me of high school. Constructing a green roof garden. We have the genius (see stupid) idea to go order 20 large waters from McDonalds. They just tell us to drive forward and park. Sure enough, not long later, they bring us 20 large waters!
- smt88 9y ago
  An interaction that cost McDonald's under $2 and is something you won't forget and will actually tell others about. Sounds like they got their money's worth.
sashk 9y ago
This reminded me about call to Starbucks during the iPhone announcement in 2007 -- https://youtu.be/bd6dQmN-mPw?t=34s https://youtu.be/bd6dQmN-mPw?t=34s

_pmf_ 9y ago

> A real method of securing APIs would be a godsend, but in current tech it's just not possible. This is the one place where mediocre security-by-obscurity is your only choice It's magically possible when tying it to a payment processor, though.

IshKebab 9y ago

What abuse would it be ripe for exactly? I assume the only thing they were trying to prevent is third party apps.

bpicolo 9y ago
Say a third party app orders the wrong coffee, or orders too much stuff, etc. There's a real business risk because they have to shell out physical capital to make coffee. I might be slightly off because thinking about it the app probably requires up-front payment. But either way, fully open APIs can cause problems if they're more meant for internal processes
prawks 9y ago
One funny (ab)use case that may not be immediately obvious: any public API that accepts payment for goods via credit card will sooner or later attempt to be used by carders to test purchased/stolen card lists for validity.
- lsaferite 9y ago
  So? You mitigate this on the server since you can never trust the client.

sowbug 9y ago

You can get pretty far with a secure element. Server challenges with signed payload of nonce + current timestamp, and client verifies it and then re-signs the payload. For something like a third-party coffee-ordering app, the economics of the usual attacks don't scale (either physically tearing apart the chip or exploiting a vulnerability in the first-party app).