The Difference Between a Bug and a Feature (And Why It Matters)

I once reported a "bug" that turned out to be a feature.

Felt stupid. Wasted the triager's time. Wasted my own time.

The developer had intentionally added that behavior. It was working exactly as designed. I just didn't understand the product.

That's when I learned the hard lesson. Not everything weird is a vulnerability.

– -

What Actually Makes Something a Bug

A security bug means an attacker can do something the owner didn't intend.

That's it. Not "this looks odd." Not "this doesn't match best practices." Not "this error message is ugly."

Can someone actually do harm? Steal data? Take over an account? Bypass a payment? Break a rule that matters?

If yes, it's a bug. If no, keep looking.

– -

The Gray Area That Catches Everyone

Some things feel like bugs but aren't.

Missing security headers on static files. Everyone reports this. Almost never a real issue. Can an attacker actually do anything with it? Usually no.

Information disclosure in error messages. Sometimes real. Sometimes just a custom 404 page that looks scary but gives nothing useful. Check if actual sensitive data is leaking. Not just "there was an error."

Rate limiting missing on login. This one is real but low impact unless there's no password policy. Can you actually brute force? Test it before reporting.

Self-XSS. You can only attack yourself. Not a bug. Move on.

Clickjacking without sensitive actions. If there's nothing to click that actually does harm, it's not worth reporting.

– -

How I Learned to Tell the Difference

I started asking three questions before every report.

Question 1 – What can an attacker actually do with this?

Not "theoretically." Actually. Can they steal data? Take over accounts? Make purchases? Break something important?

If the answer is "annoy the user" or "maybe something in the right circumstances," it's probably not a bug.

Question 2 – Does the owner consider this a problem?

Read the program's scope. Some accept missing security headers. Some don't. Some want clickjacking reports. Some don't.

If they explicitly say they don't accept something, don't report it. You're wasting everyone's time.

Question 3 – Would I pay for this if I owned the site?

Be honest. If you ran this company, would you write a check for this finding? Or would you close it as informative?

If you wouldn't pay, don't report.

– -

The Report I Wish I Never Sent

I found a page that loaded over HTTP instead of HTTPS. On a site that otherwise used HTTPS everywhere.

I was so excited. Mixed content! This is bad!

Then I realized the page only showed public information. No logins. No data. Nothing sensitive.

The triager marked it informative. They were right. It wasn't a real issue.

Now I check impact before impact. If there's no harm, there's no bug.

– -

What You Should Actually Report

IDORs. Always. Easy impact. Easy to explain.

XSS that actually executes. Not reflected in a parameter that never renders. Real XSS.

Authentication bypass. Can you log in as someone else without their password?

Privilege escalation. Can a normal user do admin things?

Information disclosure of sensitive data. Emails, addresses, phone numbers, private messages, API keys.

Business logic flaws. Can you get something for free? Discount abuse? Points manipulation?

These pay. The other stuff usually doesn't.

– -

The One Exception

Sometimes you find something weird. You're not sure if it's a bug. But it feels important.

Report it. But be honest. Say "I'm not sure if this is a vulnerability but here's what I found."

Triagers appreciate honesty. Sometimes it's nothing. Sometimes you found something they didn't expect.

I did this once with a weird behavior in a password reset flow. Wasn't sure. Reported anyway. Turned out to be an account takeover. Paid $1500.

So report the weird stuff. Just don't call it a critical RCE when it's not.

– -

Ever reported something that turned out to be a feature? Drop your story in the comments. We've all been there.

If this saved you from a wasted report, clap and follow.

Want more daily bug hunting content? Connect with me on LinkedIn: https://www.linkedin.com/in/bughunter