A Beginner's Story from Curiosity to Discovery

I started my testing session like I usually do — picking a target and looking for an entry point.

This time, the application had an AI assistant feature.

That immediately became my attack surface.

The First Thought: Prompt Injection

Since it was an AI feature, my first instinct was obvious — prompt injection.

I spent time trying:

  • Direct prompt injection
  • Indirect prompt injection

I experimented with different variations, trying to manipulate responses or extract unintended behavior.

But honestly?

Nothing impactful came out of it.

At this point, many beginners would stop here and assume:

"Maybe this feature is secure."

But that's where mindset matters.

Changing the Approach

Instead of sticking to just one attack type, I asked a simple question:

"What else can be possible here?"

So I explored other common attack vectors related to user input and rendering.

That's when I shifted focus to something often underestimated:

HTML & CSS Injection

Trying Something Very Simple

Instead of crafting complex payloads, I decided to test with basic, non-destructive HTML tags.

Here's what I used:

<b>test</b>
<i>italic</i>
<u>underline</u>
<h1>H1</h1>
<marquee>scroll</marquee>
<div style="position:fixed;top:0;left:0;width:100%;height:100%;z-index:9999;background:white">
  Fake overlay
</div>

No scripts. No advanced techniques. Just simple HTML and CSS.

The Moment Everything Changed

When I submitted the payload and saw the response…

The application rendered everything.

  • Bold text appeared
  • Italics worked
  • Even the <h1> tag rendered properly

But the real moment was this:

👉 The full-screen overlay actually covered the entire page

I had effectively:

  • Blocked the UI
  • Created a fake layer on top of the application

That's when it clicked.

What I Actually Found

This wasn't just HTML injection.

This was:

UI Redressing via HTML & CSS Injection

Which means:

  • The interface can be manipulated
  • Users can be tricked
  • Fake content can be displayed

Why This Is More Serious Than It Looks

Imagine this in a real attack scenario:

An attacker could:

  • Create a fake login popup
  • Overlay it on top of the real application
  • Trick users into entering credentials

Even without JavaScript, CSS alone was enough to manipulate the UI.

The Real Lesson (Important for Beginners)

This finding taught me something very important:

You don't always need advanced payloads to find real vulnerabilities.

Most beginners think:

  • "I need custom scripts"
  • "I need complex payloads"
  • "I need automation tools"

But in reality:

Even simple payloads can break applications

What Helped Me Here

  • Not stopping after one failed approach
  • Thinking beyond the "expected" attack (prompt injection)
  • Testing how the application renders input, not just how it processes it

How This Can Be Fixed

From a developer perspective, this issue exists because:

  • User input is directly rendered as HTML
  • No proper sanitization or encoding is applied

Fixes include:

  • Escaping all user input before rendering
  • Using safe rendering methods (textContent instead of innerHTML)
  • Implementing strict sanitization (e.g., DOMPurify)
  • Restricting inline styles and dangerous tags

Final Thought

That one simple payload didn't just find a vulnerability.

It gave me confidence.

It showed me that:

  • Curiosity matters
  • Simplicity works
  • And every failed attempt is just a step closer to something real

If you are starting in security testing, remember this:

Don't wait to become "advanced" to find vulnerabilities. Start simple. Stay consistent. Keep testing.