Concept on bypassing 403 pages

Bijan — Mon, 15 Jun 2026 14:41:25 +0000

On web application security, whether there's a pentest going on or hunting for vulnerabilities, there's a concept or technique for bypassing restrictions. In here we are going on details of bypassing 403 restrictions which usually lead to finding impactful vulnerabilities.

How the restriction works?

For bypassing the restriction, we need to know how it works and what it does restrict; and it's obvious that different apps use different mechanisms so, let's explore some real world scenarios.

The overall concept

For making a restriction, it has to be defined, so imagine it like a blacklist or whitelist mechanism which has to be bypassed. Now for bypassing them, you gotta understand what factors they are considering for restricting so, you would change focus on that item. Here we explore some types of restrictions:

IP restriction

It's the simplest type, turn on your VPN. But remember that the IP can be set to whitelist some static IP's (e.g the admin's specific IP) which can make your job so much harder.

Parameters restriction

As you know, in each HTTP request we have some headers or parameters in the URL (For more simplicity I'm referring to both as "Parameters"). Which they look something like these :

GET /somedirectory/?p=parameterdata
HOST: somesite.com
User-Agent: Mozilla...
Cookie: somestuff

In above HTTP request, you can see parameters with parameterdata value in URL, and Headers as HOST, User-Agent and Cookie.

Now imagine, the admin uses the Admin Cookie as he has authenticated to visit /OnlyAdmin/dash.html. So Anyone without the Admin Cookie are not allowed to visit that page. So as our small example above, when you have a random cookie (not authenticated as admin) and visit the /OnlyAdmin/dash.html, you face a 403 status code since you are not authenticated and allowed to visit that admin dashboard.

So what is happening is that there is a restriction on that parameter/header. It's defined like ==If cookie = Admin --> allowed to visit /OnlyAdmin/dash.html and if cookie !=(not equal) to Admin, return 403 and don't allow to visit.==
So you are facing a whitelisting mechanism here.

Before exploring more scenarios and bypassing them, let's have some blacklist examples too.

Sites restricting certain user agents
Restricting certain IP ranges (like people from certain country)
Restricting users who send too much requests (rate limit)
Bad user input (Like XSS, SQLi payloads)
...

So, how they are defined

Usually they are set in 3 major ways which are :

Some are defined by the WAF (web application firewall) : For example blocking IP's or malicious parameters (e.g XSS,SQLi payloads)
Some are put by the reverse proxy : similar to waf but only processes what waf allowed to go in.
Some are hardcoded by the developer (source code): like the cookie scenario we explored

In next post I explain some bypass scenarios

A bug that led to infinite likes on video sharing platform

Bijan — Mon, 15 Jun 2026 14:30:48 +0000

There's a little fun bug I found on a video sharing website, which I can't tell the name of it, but I'm amazed that such bug exists on that platform cause it is more than 10 years for this platform to be online.
With this bug, you can like a video infinite times without the need to log in. So you can become pretty popular with the likes you give to your own video (since more likes cause your video to get seen by more people), or idk, offer someone else amount of likes and get money instead? Yeah this bug might not be that high impact at first glance or at all (Since I didn't investigate it further). But I'm gonna get into details here.

Normal behavior of web app (Getting a lead)

The web app let you to like a video without authorization. That's already sus isn't it? But it could track you across browsers and sessions. E.g you use Firefox to like the video, you make a private tab to like again but... you see the video is already like by you. You switch to Chrome same happens. So you know what is going on, they are tracking users with the IP!

In that moment I smiled, turned VPN on, checked the site with a fresh session, liked the video, changed IP again and ... What? Video is already liked?! First it might seem strange but, since there isn't an authentication for account to count likes (Exactly unlike Youtube), there must be a way.

And the most interesting part is that this is not known as a bug from the developer (That's how they are working more than 10 years by the way). It's a feature! This way people don't have to create and own accounts to like a video they see so it's easier for them to like the videos (Since the platform is not really popular and creating an account can take long so people would ignore and don't like and get on with their lives as they watched the video already and information was useful to them.) So the content creator would get likes easier.

The bug

As I said, they track users from IP and setting session on browser side, since we changed IP on same session but the video was already liked. So how can we Hack it for infinite likes?
Easy, change both of the IP and session cookie/token/whatever that is set on browser side, and the app won't recognize you anymore.
I changed IP while I opened a private tab, liked a random video, repeated the same loop again with a fresh IP and session, liked it again and so on. (I promise the content creator got really happy that day :) )

Automating the process

In theory, you just would need a proxy list or a script to change your system's IP while the like request is being made in fresh sessions.
So 3 steps:

Fresh session (probably selenium)
Like the video
Change IP (you can deploy scripts based on your solution (proxy,VPN,...))
Repeat

How to fix it?

Apply user account authentication for liking videos. Authentication can be applied by an OTP to user phone number for faster and more effective authentication, or force user to authenticate before watching the video at first place.

DEV Community: Bijan