Post cover image

July 21, 2026

Part II — Understanding the Internet Before You Attack It

“Every vulnerability begins with a request. To understand vulnerabilities, you must first understand the journey that request takes.”

By Yassin Hamada

6 min read

"Every vulnerability begins with a request. To understand vulnerabilities, you must first understand the journey that request takes."

Why This Chapter Matters

One of the most common mistakes beginners make is treating web applications as isolated systems.

They open a website, intercept a request with Burp Suite, change a parameter, and hope something interesting happens.

But a web application is only one small piece of a much larger ecosystem.

Between your browser and the application's backend, a single request may pass through a router, an Internet Service Provider (ISP), multiple autonomous systems, a Content Delivery Network (CDN), a Web Application Firewall (WAF), a reverse proxy, a load balancer, several internal services, and finally the application server itself.

Understanding this journey changes the way you test applications.

Instead of seeing only requests and responses, you'll begin to recognize where security controls exist, where trust boundaries are enforced, and where assumptions can fail.

Great bug bounty hunters don't just attack applications.

They understand the infrastructure that powers them.

The Internet Is a Conversation

At its core, the Internet is nothing more than billions of devices exchanging information.

Your browser asks for something.

A server responds.

That simple exchange happens millions of times every second across the world.

Behind every click is a conversation.

When you type:

https://example.com

your computer doesn't magically know where that website lives.

Instead, it begins a carefully orchestrated process involving several independent systems, each responsible for a different part of the communication.

Understanding those systems is the first step toward understanding web security.

Step One — DNS: Finding the Destination

Imagine trying to visit a friend's house without knowing their address.

You know their name, but names aren't enough for navigation.

The Internet works the same way.

Humans prefer names like:

github.com
openai.com
example.com

Computers communicate using IP addresses instead.

Before your browser can contact a website, it needs to discover the server's IP address.

This is the job of the Domain Name System (DNS).

DNS acts as the Internet's phonebook.

Your browser asks:

"What is the IP address for example.com?"

A DNS server replies with something like:

93.184.216.34

Only then can the browser establish a connection.

Why DNS Matters in Bug Bounty

Many organizations expose more assets than they realize.

Subdomains created for development, staging, testing, or internal tools often remain publicly resolvable through DNS.

Researchers spend a significant amount of time exploring these assets because forgotten infrastructure frequently contains outdated software, weak configurations, or overlooked functionality.

This is why reconnaissance often begins with subdomain enumeration.

Before testing an application, you first need to know it exists.

Step Two — Establishing a Connection

Knowing the destination isn't enough.

Your computer must now establish a reliable communication channel.

This process is handled by the Transmission Control Protocol (TCP).

TCP is responsible for ensuring that both devices can communicate reliably.

Before any data is exchanged, the client and server perform what's commonly known as the TCP Three-Way Handshake.

The process looks like this:

Client                Server
SYN  -------------------->
      <------------------ SYN-ACK
ACK  -------------------->

Once this handshake completes successfully, both sides agree that communication can begin.

Think of it as introducing yourself before starting a conversation.

Reliable Communication Matters

Unlike ordinary conversation, computers cannot afford misunderstandings.

If data arrives corrupted, incomplete, or out of order, TCP detects the problem and retransmits the missing information.

This reliability is one reason why protocols like HTTP are built on top of TCP.

As a researcher, understanding this helps explain behaviors such as connection resets, timeouts, retransmissions, and network instability during testing.

Not every unexpected response is a vulnerability.

Sometimes the network itself is responsible.

HTTP — The Language of the Web

Once a connection exists, the browser can finally communicate with the web server.

It does this using the Hypertext Transfer Protocol (HTTP).

HTTP defines how clients request information and how servers respond.

A request typically contains several components:

  • A method
  • A target resource
  • Headers
  • Optional body

For example:

GET /profile HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Cookie: session=...
Accept: application/json

The server processes the request and returns a response containing a status code, headers, and often a body.

Everything you intercept in Burp Suite follows this basic structure.

Learning HTTP is less about memorizing methods and more about understanding the conversation taking place between client and server.

Understanding HTTP Methods

Every request has an intention.

The HTTP method communicates that intention.

Some common methods include:

GET retrieves information without modifying server-side data.

POST submits new information to the server.

PUT replaces an existing resource.

PATCH updates part of an existing resource.

DELETE removes a resource.

While these definitions seem straightforward, real-world applications frequently implement them inconsistently.

A researcher should never assume that a request behaves exactly as its method suggests.

Developers sometimes place sensitive actions behind GET requests.

Others accept unexpected methods altogether.

Understanding the intended behavior allows you to recognize deviations.

Status Codes Tell Stories

Many beginners focus only on response bodies.

Experienced researchers pay equal attention to status codes.

A status code often reveals how the server interpreted your request.

Some examples include:

200 OK — The request succeeded.

201 Created — A new resource was created.

301/302 Redirect — The client should visit another location.

400 Bad Request — The server rejected malformed input.

401 Unauthorized — Authentication is required.

403 Forbidden — Authentication succeeded, but access is denied.

404 Not Found — The requested resource does not exist.

429 Too Many Requests — Rate limiting has been triggered.

500 Internal Server Error — Something unexpected occurred on the server.

These responses are more than numbers.

They provide insight into how the application processes your input.

HTTPS — Adding Trust to Communication

If HTTP sends information in plain text, anyone positioned between the client and server could potentially observe the traffic.

This is where HTTPS becomes essential.

HTTPS is simply HTTP running over an encrypted connection using Transport Layer Security (TLS).

Encryption protects confidentiality.

Authentication verifies the identity of the server.

Integrity ensures that data isn't modified during transmission.

Without HTTPS, usernames, passwords, session cookies, and sensitive information could be exposed to attackers monitoring the network.

Today, HTTPS is the standard for virtually every production web application.

Certificates and Trust

When visiting a secure website, your browser receives a digital certificate proving the server's identity.

The browser verifies that the certificate was issued by a trusted Certificate Authority (CA).

If verification succeeds, communication continues securely.

If verification fails, browsers display a warning because they cannot confirm who they're communicating with.

Understanding certificates becomes increasingly important when analyzing misconfigurations, testing staging environments, or identifying certificate-related weaknesses.

What Happens Before the Application Receives Your Request?

Many newcomers imagine requests traveling directly to the application server.

Reality is far more complex.

Modern organizations rarely expose backend servers directly to the Internet.

Instead, requests usually pass through multiple layers of infrastructure.

Each layer performs a different task.

Understanding these layers helps explain many behaviors you'll encounter during bug bounty testing.

Content Delivery Networks (CDNs)

A Content Delivery Network distributes website content across geographically distributed servers.

Instead of every visitor connecting to a single physical server, users connect to the nearest edge location.

This reduces latency and improves performance.

Popular CDN providers also offer caching, DDoS mitigation, and security features.

For researchers, CDNs sometimes reveal interesting behaviors involving cached content, exposed origins, or inconsistent responses between edge nodes.

Reverse Proxies

A reverse proxy sits between the Internet and the application server.

Instead of exposing backend servers directly, organizations place a reverse proxy in front of them.

The reverse proxy receives incoming requests and decides where they should go.

It can perform tasks such as:

  • SSL termination
  • Header manipulation
  • Authentication
  • Request filtering
  • Logging
  • Compression

Many security controls exist at this layer rather than inside the application itself.

Recognizing proxy behavior can explain unexpected headers or routing decisions during testing.

Load Balancers

As applications grow, one server becomes insufficient.

Organizations deploy multiple application servers behind a load balancer.

The load balancer distributes incoming requests across available servers.

From the user's perspective, nothing changes.

Behind the scenes, dozens or even hundreds of servers may process requests simultaneously.

Understanding load balancing helps explain inconsistent responses, race conditions, and session-related anomalies.

Web Application Firewalls (WAFs)

Before requests reach the application, many organizations inspect them using a Web Application Firewall.

A WAF attempts to detect and block malicious traffic.

It may inspect URLs, headers, request bodies, cookies, and query parameters.

If suspicious behavior is detected, the request may be blocked before the application ever sees it.

This explains why some payloads return immediate blocks while slightly modified versions succeed.

Learning to distinguish WAF behavior from application behavior is an important research skill.

The Complete Journey of a Request

By now, the process should feel much clearer.

A simplified request lifecycle looks like this:

Browser
    │
    ▼
DNS Resolution
    │
    ▼
TCP Connection
    │
    ▼
TLS Handshake
    │
    ▼
CDN (Optional)
    │
    ▼
Web Application Firewall
    │
    ▼
Reverse Proxy
    │
    ▼
Load Balancer
    │
    ▼
Application Server
    │
    ▼
Database / Internal Services
    │
    ▼
Response Returned to Browser

Every layer has its own responsibilities.

Every layer introduces its own assumptions.

Every layer has the potential to contain security weaknesses.

As researchers, our job is to understand where trust begins, where it ends, and what happens when those assumptions are challenged.

Key Takeaways

By the end of this chapter, you should understand that a web request is not a simple message sent directly from your browser to an application.

Instead, it travels through a complex ecosystem designed to improve reliability, performance, scalability, and security.

Each component — DNS, TCP, HTTP, TLS, CDNs, reverse proxies, load balancers, and firewalls — exists for a reason.

The better you understand those reasons, the easier it becomes to recognize unusual behavior during security testing.

Many vulnerabilities don't appear because developers wrote insecure code.

They appear because two systems trusted each other more than they should have.

Recognizing those trust boundaries is one of the most valuable skills a bug bounty hunter can develop.

Coming Up Next

Now that we understand how requests travel across the Internet, it's time to examine the operating system from which those requests originate.

In the next chapter, we'll explore Linux — not as a collection of terminal commands, but as the environment that powers much of the modern Internet.

Understanding files, processes, permissions, networking, services, logs, shells, and automation will give you the confidence to work efficiently, analyze systems more effectively, and build the foundation needed for every stage of bug bounty hunting.

— Yassin Hamada Cybersecurity Researcher | OSINT · Malware Analysis · Threat Intelligence