Zero: SeeingWhat’s Hidden

Chapter 4 == "Web Security" ─[The real battle starts here]

So far, we've looked, gathered, and observed. Now we're really starting to talk to the systems. Web security is not "looking for holes," as most people think. Web security is about understanding how a system thinks. If you truly understand HTTP, the rest is just details. That's it. No more, no less.

1)HOW DOES HTTP WORK?

The web is actually a very simple conversation. One side asks, the other side answers, that's all. But the conversation is so fast and repeated so many times that we think it's magic.

HTTP (Hyper Text Transfer Protocol) is the common language between the browser and the server. When you visit a site, something like this happens in the background: "Hello, I want this page." "Sure thing, here's the page." The point of HTTP is not to be complex, but to be clear. HTTP is like a conversation. This conversation consists of two main parts:

Request (Request) -> you speak.

Response (Answer) -> the server responds.

The browser is always the first to speak. The server never sends you anything out of the blue. This is an important detail because most vulnerabilities in web security arise from this conversation being unexpectedly redirected.

What does a Request contain?

An HTTP request typically states:

• What do I want? (e.g., /login, /profile)
• -How do I want it? (GET or POST?)
• -Who are you? (Cookie, session information)
• -What are you sending? (Form data, parameters)

So, essentially, the browser sends a small letter to the server. And the content of that letter can be changed. Stop here. Keep this sentence in mind.

What does the response contain?

The server doesn't just sit there; it responds too:

• Did I succeed? (200)
• -Couldn't find it? (404)
• -No permission? (403)
• -Did something go wrong? (500)

And of course:

• HTML
• -JSON
• -File
• -Or just a message

Web applications behave according to these responses. But they don't always make the right assumptions. This is where security comes in.

Why are GET and POST important?

Most people memorize this but don't fully understand it:

• GET-> "I want to look"
• -POST -> "I'm sending something"

But the real difference is this: GET is generally visible. POST is usually hidden. And people think that what's hidden is more secure. It isn't. The server takes whatever it receives. How it arrives is often irrelevant. HTTP is stateless (it has no memory). This is very critical. HTTP has no memory. Each request is evaluated on its own.

So how do websites remember me? Answer: Cookies, sessions, tokens.

So HTTP is forgetful, but we stick notes on it to help it remember. And those notes… sometimes get stuck in the wrong place.

Why does web security start with HTTP? Because:

• XSS happens here.
• -SQL Injection passes through here.
• -IDOR is hidden here.
• -Authentication errors leak here.

If you don't understand HTTP:

-You memorize the vulnerability.

-But you won't understand why it works.

If you truly understand HTTP: -You sense the vulnerability without seeing it.

The essence of this section: HTTP isn't magic, it isn't complicated, but it doesn't tolerate carelessness. If you want to advance in web security, you must first learn to hear this conversation because soon we'll start listening to it in a way others don't notice. And ultimately; the server trusts you because it has to, and forced trust is the weakest point.

2) THE MOST COMMON 10 VULNERABILITIES "OWASP TOP 10"

(Not a list of errors, but a map of human weaknesses)

OWASP Top 10 is often explained like this: item by item, memorized, forgotten after the exam. But the truth is: This list is not a record of technical vulnerabilities, but a recurring pattern of human behavior.

Code changes, frameworks change, but people remain the same. And that's why the same mistakes come back under different names.

1-Broken Access Control: "Who can access this?"

This vulnerability appears to be the most innocent, but it is the most dangerous. Because the underlying assumption is: "No one will try anyway." The system allows you to do what it shouldn't let you do. Not because you want to — without being asked. The door is thought to be locked, but the key is never checked.

2-Cryptographic Errors: "It's encrypted, so it's safe."

Encryption exists, but:

• In the wrong place
• -In the wrong way
• -Based on the wrong assumption

This stems not from poor math, but from haste. It is the digital equivalent of the phrase "We'll fix it later."

3-Injection (SQL, Command, etc.): "The user won't write this here"

They do. They always do. The system trusts the input because that's how it was taught. But the input is not innocent. It never has been. Injection is the system using its own language against itself.

4-Insecure Design: "It works, though."

This is the quietest vulnerability because the error is not in the code, but in the decision. Anything built on a flawed foundation will collapse, no matter how well it is written. This is obvious:

• It cannot be found through testing
• -It cannot be caught with a tool
• -It can only be detected by thinking

5-Security Misconfigurations: "The default settings are sufficient."

It is not. It never has been. Open directories, open debug modes, forgotten admin panels… All are products of the same mindset: "Who's going to bother?" Someone will.

6-Weak Authentication: "It has a password."

But:

• It's easy
• -Repeated
• -The same everywhere

This vulnerability seems to blame the user. But the real fault lies with the system that does not recognize the user. Humans are lazy. When the system does not take this into account, it pays the price.

7-Software and Data Integrity Errors: "This file is reliable."

Who said so? If something works, it is assumed to be reliable. But sometimes the attack is the file itself. Not like an update, it corrupts it from within.

8-Insecure Logging and Monitoring: "If something happens, we'll look into it."

But there are no logs to look at, or there are logs but no one reads them. An attack occurs, the system remains silent. This vulnerability thrives on being undetected. Because if it goes unnoticed, it's as if it never happened.

9-SSRF and Similar Security Breaches: "The server is talking to itself."

And that's exactly why it's dangerous. The system trusts internal elements unconditionally. But sometimes the outside behaves like the inside. The biggest vulnerabilities occur in the places thought to be the most secure.

10-Legacy Components: "It hasn't caused any problems for years."

They may not have caused problems, but that doesn't mean they won't. They don't become obsolete over time; they become known over time, and known things become targets.

In summary: The OWASP Top 10 is not a "checklist," it is a warning. It says: The biggest vulnerability is where you say, "There's no need for that." Those who question the assumption rather than the system win.

3) XSS — SPEAKING THROUGH SOMEONE ELSE'S MOUTH

XSS is often described as "a scripting vulnerability." This definition is correct but incomplete. XSS is less about a coding problem and more about forgetting who owns the identity.

What XSS is not: XSS is not:

• not taking over the server
• -not blowing up the database
• -not destroying the system

XSS is silent, inconspicuous, and therefore dangerous.

What is XSS?

XSS is this: When a system should say "this is mine," but instead claims someone else's words as its own.

When a browser opens a page, it believes: "This content belongs to the site." XSS arises precisely here. Because sometimes the content:

• Comes from the user
• -Is a comment
• -A message
• -A search result

But the system has forgotten to distinguish between them. And the browser is fooled.

A simple thought experiment: Think of a website. It has a comment section. You write a sentence there, and the system says: "Okay, I'm putting this on the page." But that sentence isn't just words; it also contains instructions. The browser reads and executes them. But it thinks: "The site is saying this." This is the moment when XSS is born.

Why is XSS so dangerous? Because XSS:

• Attacks the user
• -Targets trust
• -Speaks from within

With XSS:

• Sessions are stolen
• -Accounts are compromised -
• Users are tricked

And the worst part is: The victim doesn't even realize they've been attacked. Everything looks normal. The site is familiar, the address is correct, but it's no longer the site speaking.

XSS is not a technical vulnerability, it is a role confusion. The system hasn't asked the question: "Who said this?" And when this question is not asked:

• the browser decides
• -the user pays the price

XSS occurs "in a trusted place" because no one trusts anything coming from outside. But everyone trusts the voice from within.

The Dark Side XSS attacks are rarely flashy. Most of the time:

• It's a link
• -A message
• -A notification

But when you click that link: You cease to be yourself. A sentence written by someone else speaks with your identity.

XSS teaches you this: Security isn't about "what works sometimes," but "who is speaking." In a system where content and commands cannot be distinguished, there is inevitably a confusion of voices. And the voices that mix tell the most dangerous stories. Now let's look at the types of XSS:

XSS is not a single thing. It is three different reflections of the same flaw, and the common point in all of them, as I mentioned earlier, is this: The system cannot distinguish the speaking voice.

1. Reflected XSS (Instant Whisper):

Reflected XSS is a one-time occurrence. It lives in a link, is stored in a parameter, and only speaks when clicked. The victim clicks the link, the server returns the response, and the browser executes what is told. Then it's over. But that single moment is enough for a session.

2. Stored XSS (Persistent Trace):

Stored XSS is silent but persistent. In a comment, in a profile, in a message. The system stores it and serves it repeatedly to every incoming user. Here, the attack is no longer about the attacker. The system spreads on its own. This is the most dangerous type of XSS because it is persistent and often goes unnoticed.

3. DOM-Based XSS (Even the server is unaware):

In DOM-based XSS, the server is innocent. Everything happens within the browser. JavaScript takes the data, interprets it, and places it in the wrong location. The server sees nothing, there are no traces in the logs, but the browser continues to communicate.

Therefore: Some vulnerabilities are not reported but affect users. All three say: The question "Is this data secure?" has not been asked. The code worked, the site opened, but no boundaries were set. XSS shows you this:

• All incoming data is suspicious.
• -Not all visible text is innocent
• -Trust is not built on assumptions

And perhaps most importantly: The browser is not on your side; it only does what it is told. When XSS is closed, the door is not locked. It only writes this sentence: "Who is speaking?" Systems that ask this question are less impressive but last longer. And now… the system has come to its own language.

4) SQL INJECTION

(The system trusts you, and that's where the problem begins.)

A system asks you for information. Your name, your password, a word, a number… The system must obtain this information because it must trust humans in order to function. SQL injection arises precisely here.

This is not a vulnerability; it is a flawed assumption. The system assumes: "What is given to me is merely data." But sometimes what is given is a sentence, and sometimes that sentence is written in the system's own language. Consider a database. There are tables, rows, columns — everything is organized, everything makes sense. The system is asked questions: Does this user exist? Is this password correct? These questions are asked millions of times every day, and most of the time, the answers come back silently.

But the system makes this mistake: It doesn't separate the question from the answer. It doesn't check where the sentence ends. What happens in SQL injection is this: You don't force the door, you don't break the lock, you don't look for a back door. You simply do this: "You rewrite the sentence the system asks."

Consider an input field: username, password. The system takes these fields and adds them to a query within itself. This query is an instruction for the machine. But the system doesn't ask: "Is this really a name?" or "Is this just a password?" Because the machine doesn't understand intent; it only sees syntax. And if what you give it is in the language the system understands, it takes it seriously. This is where data turns into a command. The danger of SQL injection lies not in its power, but in its simplicity.

Most of the time, complex things aren't needed. No exploit chain, no advanced tools… Just an unchecked input is enough. That's why SQL injection still exists. Even though it's been explained for years, despite being known for years. Because the problem isn't technical; it's a mindset issue. Systems demand speed. Developers want to keep up. Checks are postponed. Assumptions are accepted. And in the end, the system ends up teaching its language to the wrong person.

SQL Injection shows us this: The most dangerous vulnerabilities aren't the most complex ones, but the most human ones. Because people often rush, and systems learn from people. The next step is no longer to speak the language of the database, but to understand what the browser accepts. And there, a small gap sometimes turns into a mirror that everyone can see.

SQL Injection teaches us this: No matter how powerful a system is, if it doesn't know what to believe, it can believe the wrong thing. The issue here isn't the code. The issue is accepting without questioning. And most systems make their biggest mistake right here. Because sometimes the most dangerous thing isn't the system granting you "permission," but it thinking you're authorized.

From now on, we no longer question the statements themselves, but the identity itself, and sometimes the doors aren't locked — they've simply never been checked to see who they're open to.

5) IDOR — DOOR OPEN BUT NO ONE NOTICED

Some angles are noisy, cause errors, trigger alarms, and leave logs. IDOR is silent. Because in IDOR, the system works, everything is as it should be. At least, that's what it seems like.

The acronym IDOR is simple: Insecure Direct Object Reference, but what it describes is much more than just a technical term. Imagine a system. There are users, accounts, files, orders, messages… And everything is represented by a number. A user wants to view their own data. The system does this: "Go to this number and display it." But the critical question is not asked: "Do they have the right to go to that number?" IDOR arises precisely here.

Think of a URL. Simple, clean, innocent. A number changes, a parameter increases, and suddenly the system starts showing you something that doesn't belong to you. There is authentication, but no authorization. The system recognizes you, but it can't distinguish what you should be accessing.

IDOR is dangerous because it often doesn't look like a "hack." There's no payload, no complex technique, no sense of an attack. There's only this question: "What if this number belongs to someone else?" and the system can't answer it. IDOR shows us that security is not always about the question, "Can I get in?" It's about "How far can I roam inside?" Most systems lock the door but forget to separate the rooms. And sometimes the most valuable information sits in the most unprotected place because no one thought anyone would look there.

Sometimes it's not the systems that make mistakes, but the users, and the systems are very good at hiding those mistakes.

6. AUTHORIZATION ERRORS

(The system recognizes you but doesn't know your limits.)

Imagine a system. You can log in, your identity is verified, and now you're "inside." But being inside doesn't mean you belong everywhere. Authorization errors start right here. The system should ask you, "Who are you?" and immediately follow up with, "What can you do?" But most systems stop at the first question.

Authorization defines the limits of your identity. It tells you where your authority begins and ends, and the dangerous part is this: Authorization errors usually don't "break" things. Everything works, pages open, transactions complete. Just to the "wrong person."

If a user can perform an action belonging to an administrator… If a role can see an area that doesn't belong to it… If a system has forgotten to say "you can't do that"… There's a vulnerability there. And this vulnerability doesn't scream; it's silent because the system is internally consistent. It's just "unfair."

Authorization errors teach us this: Security is as much about what someone can do inside as it is about who gets in. And often the biggest problem is giving too much permission. Because no one wants to say "no."

7) SSRF, RCE, and ADVANCED VULNERABILITIES

(When the system starts talking to itself)

At this point, we move beyond simple vulnerabilities. The issue is no longer the user. The issue is the system itself.

Vulnerabilities like SSRF and RCE may seem intimidating at first glance; their names alone sound daunting. But their essence is simple.

SSRF asks: "Where can this system look on my behalf?" If a system is fetching data from outside, going to a URL, pulling a resource… And if you can control that… The system can open up its inner world to you. And sometimes the system's most sensitive parts aren't on the internet, but looking at itself.

RCE is even quieter because here you no longer write the commands. The system thinks it's writing them. It takes an input, performs an operation, but doesn't check what it's running. And what happens at that moment is this: The system mistakes your thoughts for its own behavior.

Such vulnerabilities are not rare. They are just noticed late. Because no one thinks the system will harm itself. But systems are written by humans, and humans can't consider every possibility.

By the end of this section, you should understand this: The real danger isn't complex vulnerabilities. The real danger lies in those moments when people say, "This will never happen." In this section (Chapter 4), the battle has begun, but there is no chaos yet. You now know this: Web security is a mindset before it is a tool. Logic errors come before code. Assumptions come before attacks. And most systems are vulnerable precisely where they think they are secure. In the next section, we won't talk about power; we'll talk about control.