When Features Do More Than They Should

Some security issues don't come from complex systems or clever exploitation. They come from ordinary features doing slightly more than intended.

I recently reported a vulnerability on OLX and was added to their Hall of Fame. I can't share the details, but the takeaway is simple: even the most routine functionality can introduce risk when boundaries aren't clearly defined.

The Illusion of "Simple"

Applications are full of features that feel straightforward:

• Submit
• Update
• Trigger

Individually, they're easy to understand. They're often built quickly and reused across different parts of the system.

But in a real-world application, nothing operates in isolation. Every feature interacts with:

• Data in different states
• Background workflows
• Other system assumptions

And that's where things start to drift.

The Gap Between Existence and Eligibility

A common pattern behind these issues is a missing distinction:

Something exists in the system, but that doesn't mean it should be actionable.

Systems often validate whether something is real, but not whether it is appropriate to act on.

That gap — between existence and eligibility — is where subtle bugs appear.

When Workflows Trust Too Much

Modern platforms rely heavily on automated workflows. These workflows are usually triggered by user actions and are designed with certain assumptions in mind.

Problems arise when those assumptions aren't enforced.

If a workflow trusts that:

• the input is valid
• the context is appropriate
• the timing makes sense

without explicitly checking those conditions, it can be triggered in unintended ways.

Nothing is technically "broken" — the system is just being used outside the scenario it was designed for.

Why This Is Hard to Catch

These issues don't always look like security vulnerabilities:

• No obvious access control bypass
• No clear data exposure at first glance
• No system crash or failure

Instead, they show up as:

• Actions happening at the wrong time
• Processes being triggered too early or in the wrong context
• Internal logic behaving inconsistently

Because of that, they're often dismissed as edge cases or product quirks rather than security problems.

A More Useful Question

When testing or building features, a better question than "does this work?" is:

"Under what conditions should this not work?"

That shift in thinking surfaces gaps that traditional testing often misses.

A Simple Principle

Every action in a system should implicitly answer three things:

• Is this allowed?
• Is this the right time/state?
• Is this the right context?

If any of those are assumed instead of enforced, the system becomes easier to misuse.

Closing Thought

Most vulnerabilities aren't about breaking systems. They're about understanding how systems behave when their assumptions are stretched.

And sometimes, all it takes is a perfectly normal feature being used in a slightly abnormal way.

—

Asjad Butt Security Researcher

🔗 LinkedIn: https://www.linkedin.com/in/asjad-butt/ 🐞 Bugcrowd: https://bugcrowd.com/h/asjadbutt 💻 GitHub: https://github.com/asjadbut