2 ms·

There's only been one time that did real damage. Talked with a security firm, got an audit, and the bad guy did a good enough job of covering their tracks (did

by fizx 5y ago

There's only been one time that did real damage. Talked with a security firm, got an audit, and the bad guy did a good enough job of covering their tracks (did the recon with their account, actual attack over TOR) to make it hard to prosecute. Another time, when one of our competitors was creating a bunch of spam accounts on our app, we just had our VC call their VC. They blamed it on an intern and stopped. I was at a drinking event at a conference 3 years after an acquisition talk fell through, and an employee of the acquirer told me that they got our customer list from a specific endpoint manipulation, and that caused them to lose interest. Everyone tries querystring and url manipulation. It's too tempting not to poke around. In the real world, you can't prosecute any of this.

echelon 5y ago
> they got our customer list from a specific endpoint manipulation - Never use monotonically increasing IDs as the keys for GET endpoints of single entities. These can be enumerated. Only use tokens composed of random entropy for externally facing keys. - Carefully consider what your list endpoints reveal. Scope them down to the minimum possible result set. As a bonus, encrypt your cursoring API so it doesn't leak information about your scale. This isn't hard to do. Send down an opaque encoding of pagination state that is server side encrypted and that the client code never needs to unpack. The client just sends the direction, sort key, and encoded token.