Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse-engineering the Starbucks ordering API

blog.tendigi.com

Post reply on HN
Print view View original

131–140 of 157 posts

Re: Reverse-engineering the Starbucks ordering API

#131

Post by laythea »

CodeWriter23 wrote: post #83
joombaga wrote: post #45

I did this with the Papa John's webapp a while back (which was waaaay simpler btw). They limited duplicate toppings to (I think) 3 of the same, but "duplicate_item" was just a numerical property on the (e.g.) "bacon" object. Turns out you could just add multiple "bacon" members to the toppings array to exceed the limit, and they didn't charge for duplicates, so I ordered a pizza with like 50 bacons. It definitely did…

I'm not a lawyer but I'm pretty sure yours would advise against confessing to theft and wire fraud in a public forum.

I think this is an overreaction. The comeback realistically = 0. PS. Not advocating illegalities :)

Re: Reverse-engineering the Starbucks ordering API

#132

Post by sluggg »

CodeWriter23 wrote: post #85
vinhboy wrote: post #62

Earlier quoted context omitted.

Agreed. I'd also add that the UI for the app needs work. Ordering coffee for a group of people becomes a huge hassle on my phone because their search is not precise, and customizing drinks is a bit cumbersome. I spent like 20 minutes trying to order 5 drinks the other day. It was also annoying because when I left the app, all my selected items disappeared.

I'd call that an app fail, taking more time to use the app than writing a list then walking there and back with your complete order.

I would not. Ordering a large group of people drinks from Starbucks is not in any way the primary use case for the application. For it's primary use cases (paying at the store, rewards redemption/collection, ordering yourself drinks ahead) it works perfectly.

Additionally, if you think about the feature set that would be required to facilitate bulk orders then you will quickly find that it would be quite large feature set and require it's own flow. The app does has new-ish features that allow you to re-order prior orders and save drinks, which would help for these bulk orders, so they are making progress. If you are consistently ordering drinks for a large group of your co-workers then you can save their drink preferences and boom.

Re: Reverse-engineering the Starbucks ordering API

#133

Post by gmemstr »

rconti wrote: post #41

Excellent writeup. I have to take issue with the "Starbucks app is great" line, though. I think I've had more problems with it (on iOS) than any other app. It's the only app that (for a period of many months if not a year) was regularly unable to find my location. Even if I opened up Maps or some other location enabled app and found my location before launching Starbucks, it would just bomb out. Overall the app seems…

Here's a little story about how my gold card was disabled;

I was ordering coffee and my balance wasn't quite sufficient. I reloaded it via PayPal, but the balance didn't update so I tried again (it did error out). The app crashed, I reopened it and found it had added both transactions to my account. Open dispute on PayPal for just one of the transactions, got a refund but my card was completely locked out - $0 balance, couldn't reload it (the dispute was after I tried contacting support). So now I don't go to Starbucks.

Re: Reverse-engineering the Starbucks ordering API

#134

Post by shortstuffsushi »

ballenf wrote: post #113
shortstuffsushi wrote: post #48

Earlier quoted context omitted.

Why would their API need to be anything more than what they offer to their app? Why not something like "hey, you can use our stuff, but you've only got access to the same set of APIs we use in our app, and we may change it as we please. Oh btw, here are the auto-gen'd docs, hope those are enough" That seems like it'd be both developer friendly and no more maintenance than they're already putting into it. The alternat…

You can't data mine users as much. You can't easily advertise specials or high margin items. Not that i think those are legitimate, but if a 3rd party app became popular and easily accessible, the company would lose the control over their perception.

You're not wrong, this does give up that sort of control. That's a different issue, but certainly a reason why they might not want to do it.

Re: Reverse-engineering the Starbucks ordering API

#135

Post by coworkerblues »

cwsx wrote: post #72
coworkerblues wrote: post #64

I want to write a similar write-up for a company which basically does everything over HTTP with their own half-baked hardcoded AES key in app for sending credit card info. and that their confirmation checkup is stupid (for SMS) and can be bypassed. The problem is that their site TOS forbids reverse engineering, and I am afraid their lawyers will go after me instead of fixing the security issues (even if I just contac…

Just formally ask the company, if they don't want you to they will tell you. Could be worth including a pitch of sorts ('Hey, Ive noticed a few problems using your site...') but MAKE SURE you don't incriminate yourself. Do NOT show evidence of you 'reverse engineering' anything. Do not do anything without gaining permission, as there's a very good chance you're going to run into their legal team.

I don't want to contact them in a way that they can trace me, since I'm pretty sure that they will try to covert up / threat me (I would hope that someone there already knows this is an issue....).

Re: Reverse-engineering the Starbucks ordering API

#136

Post by coworkerblues »

Rjevski wrote: post #100
coworkerblues wrote: post #64

I want to write a similar write-up for a company which basically does everything over HTTP with their own half-baked hardcoded AES key in app for sending credit card info. and that their confirmation checkup is stupid (for SMS) and can be bypassed. The problem is that their site TOS forbids reverse engineering, and I am afraid their lawyers will go after me instead of fixing the security issues (even if I just contac…

Disclose everything over Tor. The kind of scum that sends credit card data over insecure homebrew crypto deserves no mercy.

I would rather contact them anonymously first, also I don't understand exactly how Tor would help me with this.

Re: Reverse-engineering the Starbucks ordering API

#137

Post by prawks »

IshKebab wrote: post #98
bpicolo wrote: post #6

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 =(

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

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.

Re: Reverse-engineering the Starbucks ordering API

#138

Post by zilian »

semi-extrinsic wrote: post #90
spike021 wrote: post #75

Maybe a bit off-topic, but APIs always make me wonder a bit when they can be reverse-engineered or.. for lack of a better word, misused. I know of one website (site A) that sells items for sports and uses an API of a sports website (site B) to provide current statistics and other information. Thing is, that sports website's API is now deprecated for public use, there's no way to request a token, and from what I can t…

I was looking at statistics for prices of sold houses in a European country a few years back, and started digging around in the javascript of a local newspaper that every month listed the local sold properties. Turned out in the API they were using from the central statistics provider, they just had "days=30" and "municipalities=[list]". They weren't even caching it, every user visiting the page was another (identica…

I am really curious which country you're referring to.

Re: Reverse-engineering the Starbucks ordering API

#139

Post by Budweiser »

I want to write a similar write-up for a company which basically does everything over HTTP with their own half-baked hardcoded AES key in app for sending credit card info. and that their confirmation checkup is stupid (for SMS) and can be bypassed.

The problem is that their site TOS forbids reverse engineering, and I am afraid their lawyers will go after me instead of fixing the security issues (even if I just contact them), any tips?

Post reply on HN