The two parts where this person (I'm guessing you, OP) went wrong:
A company that wasn’t any kind of direct competitor announced they’d start issuing credit cards (then turning into direct competitors), and I started to became more and more curious about what they were building as I knew some (pretty good) people working there.
After reading that they had launched some card stuff on their production app, I downloaded it and looked for card-related assets (it was something really simple, unzipping a .ipa file and looking for images/texts)
Step one here essentially throws away any plausible deniability you have that you weren't trying to do competitive analysis. You became toxic the moment you took it upon yourself to do this without any kind of protection in place.
Setting aside the data access issues, at a bare minimum your employer couldn't any longer guarantee that code you wrote wouldn't just get them sued.
The mock I used specified a card ID… the app then requested the number for that.
Something that I, logged in as a user without any credit cards, should be denied access to. But… There it was. And… in plaintext.
Having worked on some projects regarding credit cards and such I first thought they were running some kind of test environment on production, as this was a pilot that only employees (of a small team of them) should have access to.
“Maybe it’s even a static file being served on this route”. Couldn’t help myself but do one more request changing the ID. Brought another card number and name.
After seeing the plaintext data in step one is where you could have plausibly stopped and maintained some semblance of deniability. It may have still shaken out the same way but it's an easier sell. Continuing to then browse other card data will get you automatically in trouble.
Regarding the rest of your outcome, I have two reads.
Assuming you're truthful, it's entirely possible someone else noticed the exact same issue at the same time and exploited this maliciously and it's going to be incredibly difficult for you to convince people it wasn't you, given you already have the track record of doing this same thing.
Assuming you're being deceitful here, there's a few warning signs along the path of the story.
Firstly, you write from the perspective of someone who believes themselves to be superior to the developers of the app you exploited. On the one hand, given what you found, I kind of get it, some of that seems like pretty basic security failings. On the other hand, in my experience this is what people who turn out to be guilty of the thing they're being charged/sued over tend to do as a way of explaining things.
Secondly, that you are communicating this at all suggests you're trying to prove you were "technically right" to do these things. Courts aren't going to care about that. Your lawyer was generally right to advise you against these things. This is now out there and will likely be used against you in a court of law.
I'm passing no judgements on whether or not it is right that you face this kind of litigation for reporting security issues; I work in security doing exactly this kind of work and the thing that often saves me is documentation, documentation, documentation. Agreements, in writing, signed by all parties, etc. Even that doesn't work sometimes.
Setting aside the data access issues, at a bare minimum your employer couldn't any longer guarantee that code you wrote wouldn't just get them sued.
After seeing the plaintext data in step one is where you could have plausibly stopped and maintained some semblance of deniability. It may have still shaken out the same way but it's an easier sell. Continuing to then browse other card data will get you automatically in trouble.Regarding the rest of your outcome, I have two reads.
Assuming you're truthful, it's entirely possible someone else noticed the exact same issue at the same time and exploited this maliciously and it's going to be incredibly difficult for you to convince people it wasn't you, given you already have the track record of doing this same thing.
Assuming you're being deceitful here, there's a few warning signs along the path of the story.
Firstly, you write from the perspective of someone who believes themselves to be superior to the developers of the app you exploited. On the one hand, given what you found, I kind of get it, some of that seems like pretty basic security failings. On the other hand, in my experience this is what people who turn out to be guilty of the thing they're being charged/sued over tend to do as a way of explaining things.
Secondly, that you are communicating this at all suggests you're trying to prove you were "technically right" to do these things. Courts aren't going to care about that. Your lawyer was generally right to advise you against these things. This is now out there and will likely be used against you in a court of law.
I'm passing no judgements on whether or not it is right that you face this kind of litigation for reporting security issues; I work in security doing exactly this kind of work and the thing that often saves me is documentation, documentation, documentation. Agreements, in writing, signed by all parties, etc. Even that doesn't work sometimes.