Change one number in the URL. See someone else's invoice.
That's an IDOR, and it's still one of the most common bugs we find in API pentests.
How it happens:
GET /api/invoices/1042 → your invoice
GET /api/invoices/1043 → someone else's invoice
The server checks that you're logged in. It never checks that invoice 1043 belongs to you.
Where to look:
• IDs in URLs, JSON bodies and headers
• "Export", "download" and "share" endpoints
• Mobile app APIs (often less tested than web)
• Old API versions like /v1/ still live next to /v2/
The fix: check ownership on every request, on the server. Not in the UI.
Bookmark this for your next code review.
@yourclouddude Good list. The one I'd add: IAM is also where most cloud breaches start. An "admin just for now" user or an access key pushed to GitHub opens everything else on this list.
A password reset bug we see far too often:
1. User asks for a reset link.
2. The app sends the link to the email in the request body.
3. Attacker sends the victim's username, but their own email.
4. The victim's reset link lands in the attacker's inbox.
Account takeover. No password guessing needed.
The fix:
• Look up the email from your database, never from the request
• Make tokens single-use and short-lived
• Kill old sessions after a reset
Scanners rarely catch this. It needs someone to think like an attacker.
@pashov Hiding the code isn't security. It slows down the people who would report bugs, not the ones who would exploit them. Unverified bytecode still gets decompiled.
A small audit beats no audit.
@IntCyberDigest If the charges hold up, the lesson for buyers is simple: ask any security vendor to show their method and evidence, not just promises.
"We can decrypt it, no ransom needed" should always come with proof.
@pentest_swissky Great map, bookmarking.
In real engagements the "boring" paths still do most of the damage: Kerberoastable service accounts, over-permissive ACLs, misconfigured ADCS templates.
@Jhaddix The supply chain angle is underrated. Teams lock down the prompt and forget the model server, vector DB and inference cache sitting on the same internal network.
SSRF into an inference endpoint is the new SSRF into cloud metadata. Looking forward to that lab.
@infinitelogins Great breakdown. Layered checks only help if each layer validates the same thing.
When the gateway, the backend and a trusted-client header each assume the others did the real check, you get exactly this.
@sunilyedla2 2FA protects the login page, not the account.
Any path that issues credentials (API keys, app passwords, OAuth tokens) before the second factor is done is a full bypass. Nice find.
@navid_rebian Most underrated skill in security: understanding how the business makes money.
Scanners know payloads. They don't know your refund policy. That's why logic bugs are still where manual testing wins.
@codewithkhalil Neither is more secure by default.
Sessions are easier to revoke and harder to misuse. JWTs scale well but come with classic mistakes: no expiry, alg confusion, weak signing secrets, sensitive data in the payload.
Pick for the use case, then implement it properly.
Short-lived access tokens (5–15 min) + refresh tokens tracked server-side.
On compromise: revoke the refresh token, add the access token's jti to a denylist (Redis, TTL = remaining lifetime), and bump a per-user token version so every older token fails.
"Stateless" was always a trade-off, not a rule.
@NahamSec The dupe pain is real. Upside: you now own a working chain for that sink pattern, and it will pay on the next target.
What finally cracked it, the filter or the context?
@Wakedxy1 Classic custom-module trap. sudo() with no ownership check is the Odoo version of "the framework handles auth".
Good call reporting the metadata-only leak too. Filenames and IDs alone often hand an attacker the next target.
@h4x0r_dz Fair point. Another path for people starting now: build skills on labs and bounty programs, then move into paid pentests / VAPT.
Scope is agreed, pay is fixed, and you get to test internal apps no public program will ever show you.
@tabaahi_ Impressive setup. Curious how it handles business logic bugs: a refund flow that can be replayed, or a role check that only breaks on step 3 of a workflow.
Those tend to be the ones automation struggles with. Do you hand-verify before submitting?
@mainteemoforfun Congrats, well deserved. Interesting that AI surfaced the lead. In our experience the model finds the thread and the human proves the impact.
How much manual work did it take to turn it into a valid PoC?
"We have HTTPS, so we're secure."
HTTPS protects data while it travels. That's it.
It does NOT stop:
• SQL injection
• Broken access control
• Stolen or weak passwords
• Leaked API keys in your JS files
• Business logic abuse (coupons, refunds, limits)
The padlock means the connection is private. It says nothing about what happens once the attacker is talking to your app.
What security myth do you hear most from clients? Reply below.