Post cover image

September 3, 2026

Web Application Security in 2026: Everything You Need to Know Before You Start Hacking

Web Application Security & API Security

By Amit Kumar Biswas @Amitlt2

15 min read

Web Application Security & API Security

Beginner → Practical Security Understanding

Goal:_ Understand how modern web applications and APIs work, where they become vulnerable, how security professionals identify weaknesses, and how those weaknesses are fixed._

None

1. First: What Are We Securing?

Before learning web security, understand the basic picture.

When you open a website such as:

https://example.com

you are normally interacting with several components:

YOU
              |
              | HTTPS
              v
       +--------------+
       | Web Browser  |
       | Chrome       |
       +--------------+
              |
              v
       +--------------+
       | Web Server   |
       | Application  |
       +--------------+
              |
              v
       +--------------+
       | Backend/API  |
       +--------------+
              |
              v
       +--------------+
       | Database     |
       +--------------+

A modern application can be much larger:

User
  |
  v
Browser / Mobile App
  |
  v
CDN / WAF
  |
  v
Load Balancer
  |
  v
Web Application
  |
  +-------> API
  |
  +-------> Authentication Service
  |
  +-------> Database
  |
  +-------> Cache
  |
  +-------> Cloud Storage
  |
  +-------> Third-Party Services

Security problems can exist at any point in this architecture.

2. What Is a Web Application?

A web application is software that you access through a web browser.

Examples include:

  • Online banking
  • E-commerce websites
  • Gmail-like applications
  • Admin panels
  • Learning platforms
  • HR portals
  • SaaS applications
  • Bug-tracking systems

A simple web application usually has:

Frontend
   |
   | Request
   v
Backend
   |
   | Query
   v
Database

Frontend

The frontend is what the user interacts with.

Common technologies:

HTML
CSS
JavaScript
React
Angular
Vue
Next.js

Example:

Login Page
Username: [__________]
Password: [__________]
          [ Login ]

Backend

The backend contains application logic.

It may be written using:

Java
Python
Node.js
PHP
Go
C#
Ruby

For example:

User enters username/password
            |
            v
        Backend
            |
            v
       Check database
            |
            v
       Login successful

Database

The database stores application data.

For example:

Users
-------------------------
id | name | email
1  | Amit | amit@example.com
2  | Raj  | raj@example.com

The important security point is:

The browser is controlled by the user. Therefore, you must never trust the browser.

This is one of the most important principles in web application security.

3. What Is an HTTP Request?

Your browser communicates with the server using HTTP or HTTPS.

For example:

GET /profile HTTP/1.1
Host: example.com
Cookie: session=abc123

Think of this as a message:

Browser
   |
   | "Give me /profile"
   |
   v
Server
   |
   | "Here is the profile"
   |
   v
Browser

The server responds with something like:

HTTP/1.1 200 OK
{
  "name": "Amit",
  "role": "user"
}

4. HTTP Methods

You will see several HTTP methods while studying web security.

MethodSimple meaningGETGet informationPOSTSend/create informationPUTReplace informationPATCHModify informationDELETEDelete informationHEADGet headers without the normal body

Example:

GET /users/10

means:

Give me user 10.

While:

DELETE /users/10

means:

Delete user 10.

This distinction becomes extremely important when testing authorisation.

5. What Is an API?

API means Application Programming Interface.

In very simple terms:

An API allows one piece of software to communicate with another piece of software.

For example:

Mobile App
    |
    | API Request
    v
API Server
    |
    v
Database

The mobile application does not need to directly access the database.

Instead:

Mobile App
     |
     | GET /api/profile
     v
    API
     |
     | Query
     v
 Database

The API returns the required data.

6. Web Application vs API

A web application is often designed for humans through a browser.

An API is generally designed for software to communicate with software.

For example:

WEB APPLICATION
Browser
   |
   v
HTML Page
   |
   v
User

Whereas:

API
Mobile App
   |
   v
JSON
   |
   v
API Server

Example API response:

{
  "id": 123,
  "name": "Amit",
  "email": "amit@example.com"
}

APIs are extremely important in modern applications because:

Website
Mobile App
Desktop App
Partner Application
Internal Services
        |
        v
      APIs
        |
        v
     Backend

Therefore, securing the API is just as important as securing the web interface.

7. What Is Web Application Security?

Web Application Security, often called Web AppSec, is the practice of protecting web applications from security weaknesses and attacks.

The basic objective is:

WEB APPLICATION
                    |
       +------------+------------+
       |            |            |
       v            v            v
 Confidentiality Integrity   Availability
       |            |            |
       +------------+------------+
                    |
                    v
                Security

You want to prevent attackers from:

  • Reading data they should not see
  • Modifying data they should not modify
  • Performing actions they are not allowed to perform
  • Bypassing authentication
  • Taking over accounts
  • Injecting malicious input
  • Accessing internal systems
  • Disrupting the application

8. The Most Important Security Question

When looking at any application, ask:

Who is allowed to do what?

For example:

User A
  |
  +--> View own profile
  +--> Edit own profile
  +--> Change own password
Admin
  |
  +--> View users
  +--> Delete users
  +--> Change application settings

Now imagine User A sends:

DELETE /api/users/25

The server must ask:

Who is making this request?
        |
        v
Is the user authenticated?
        |
        v
Does this user have permission?
        |
        v
Is user 25 allowed to be deleted?
        |
        v
YES --> Perform action
NO  --> Reject request

This is authorisation.

9. Authentication vs Authorisation

These two terms are commonly confused.

Authentication

Authentication answers:

Who are you?

Examples:

Username + Password
MFA
Passkey
OAuth login
Session cookie

Authorisation

Authorisation answers:

What are you allowed to do?

Example:

Amit is authenticated.
But:
Can Amit access admin settings?
NO

Remember:

AUTHENTICATION
      =
Who are you?
AUTHORISATION
      =
What can you do?

A large number of serious application vulnerabilities involve broken authorisation.

10. What Is a Session?

After logging in, the server needs to remember that you are authenticated.

One common mechanism is a session cookie.

Example:

Browser
   |
   | Login
   v
Server
   |
   | Creates session
   v
Session ID
   |
   v
Browser Cookie

The browser might subsequently send:

Cookie: session=abc123

The server uses that session information to identify the user.

Security becomes important because if an attacker obtains a valid session token, they may be able to impersonate the user.

11. Cookies

Cookies are small pieces of data stored by the browser.

Example:

session=abc123

Security-related cookie attributes include:

Secure
HttpOnly
SameSite

Secure

The cookie should only be sent over HTTPS.

HttpOnly

JavaScript cannot directly read the cookie through normal browser APIs.

SameSite

Controls when cookies are sent in cross-site contexts and can help reduce certain CSRF risks.

A security professional should understand these attributes rather than simply memorising their names.

12. What Is JWT?

JWT means JSON Web Token.

It is commonly used in APIs.

A simplified JWT looks like:

xxxxx.yyyyy.zzzzz

It contains three parts:

Header.Payload.Signature

Conceptually:

+---------+     +---------+     +-----------+
| Header  |  .  | Payload |  .  | Signature |
+---------+     +---------+     +-----------+

The payload may contain information such as:

{
  "sub": "123",
  "role": "user"
}

Important:

A JWT payload is normally encoded, not automatically encrypted.

Therefore, sensitive information should not simply be placed into the payload because someone cannot "see" it.

The server must also correctly validate:

  • Signature
  • Algorithm
  • Expiration
  • Issuer
  • Audience
  • Token context

13. The Core Vulnerabilities You Must Understand

You do not need to memorise hundreds of vulnerability names initially.

First understand these major categories:

WEB/API SECURITY
                        |
       +----------------+----------------+
       |                |                |
       v                v                v
 Authentication    Authorisation     Input Handling
       |                |                |
       v                v                v
 Account Takeover   IDOR/BOLA        Injection/XSS

       +----------------+----------------+
                        |
                        v
                Business Logic
                        |
                        v
                Security Misconfig

The most important beginner topics are:

  1. Broken authentication
  2. Broken authorisation
  3. IDOR/BOLA
  4. SQL injection
  5. Cross-Site Scripting (XSS)
  6. Cross-Site Request Forgery (CSRF)
  7. Server-Side Request Forgery (SSRF)
  8. File upload vulnerabilities
  9. Path traversal
  10. Command injection
  11. Security misconfiguration
  12. Sensitive data exposure
  13. Business logic flaws
  14. Rate-limit weaknesses
  15. API-specific authorisation problems

14. IDOR / BOLA

This is one of the most important concepts for API security.

Imagine:

GET /api/users/100/profile

You are user 100.

The application correctly returns your profile.

You change:

GET /api/users/101/profile

and the server returns another user's profile.

The problem is not necessarily authentication.

You are already logged in.

The problem is:

Authenticated User
       |
       v
Requests Object 101
       |
       v
Server
       |
       X
Did server verify ownership?
       |
       v
NO
       |
       v
Unauthorized data returned

This is commonly described as Broken Object Level Authorisation (BOLA) in API security.

The important lesson:

Being logged in does not mean you are authorised to access every object.

15. XSS

XSS means Cross-Site Scripting.

It occurs when an application handles untrusted input in a way that allows unintended script execution in another user's browser.

Simple conceptual flow:

Attacker Input
      |
      v
Web Application
      |
      | Unsafe output
      v
Victim Browser
      |
      v
Unexpected JavaScript execution

There are different types, including:

Reflected XSS
Stored XSS
DOM-based XSS

The security impact depends on the context and application.

Possible consequences include:

  • Account actions performed in the victim's context
  • Data exposure
  • Phishing
  • Defacement
  • Session-related attacks in poorly protected applications

Modern XSS prevention relies heavily on context-aware output encoding, safe frameworks, input handling, and appropriate browser security controls such as CSP.

16. SQL Injection

SQL injection occurs when attacker-controlled input changes the intended structure of a database query.

Conceptually:

User Input
    |
    v
Application
    |
    v
SQL Query
    |
    v
Database

Unsafe construction can cause:

Expected query
       |
       v
Modified query structure
       |
       v
Unexpected database operation

The fundamental defence is:

Keep data separate from SQL instructions.

Common protections include:

Prepared Statements
Parameterized Queries
Safe ORM Usage
Least-Privilege Database Accounts
Input Validation

17. SSRF

SSRF means Server-Side Request Forgery.

This occurs when an attacker can influence the server into making requests to an unintended destination.

Normal flow:

User
 |
 v
Application
 |
 v
Allowed External Website

Potentially dangerous flow:

Attacker
   |
   v
Application
   |
   v
Internal Service
   |
   v
Sensitive Resource

This is especially important in cloud environments because applications may have access to internal services that users cannot directly reach.

SSRF testing should therefore consider:

External services
Internal services
Cloud infrastructure
Network boundaries
URL validation
Redirect handling
DNS behaviour

18. Path Traversal

Path traversal occurs when user-controlled input allows unintended filesystem access.

Conceptually:

Application
     |
     | filename = user input
     v
Filesystem

If the application does not safely constrain the requested path, an attacker may attempt to move outside the intended directory.

The security objective is:

Allowed directory
      |
      +--> file1
      +--> file2
      +--> file3
NOT
Allowed directory
      |
      X
      |
Outside protected directory

Defences include canonicalisation, allowlisting, safe filesystem APIs, and strong access controls.

19. File Upload Security

Suppose an application provides:

Upload Profile Picture

A developer might think:

"Only images will be uploaded."

Security testing asks:

Does the server actually enforce that?

Important questions include:

Is the file type validated?
Is MIME type trusted?
Is the extension trusted?
Is file content inspected?
Where is the file stored?
Can it execute?
Can it be accessed directly?
Is filename controlled?
Is file size restricted?

Never rely only on a filename such as:

photo.jpg

because the filename itself is attacker-controlled.

20. Business Logic Vulnerabilities

Some vulnerabilities cannot be found simply by looking for a dangerous character or payload.

Consider an e-commerce application:

Product price = ₹10,000
Checkout
   |
   v
Payment
   |
   v
Order created

Suppose the application has a flaw allowing the user to manipulate the order process and obtain the product without paying the correct amount.

The application may have:

Valid HTTPS
Valid authentication
Valid database queries
No obvious XSS
No obvious SQL injection

Yet the application is still vulnerable.

Why?

Because the business logic is wrong.

This is why security testing is not just:

Run scanner
   |
   v
Read findings

You must understand how the application is supposed to work.

21. API Security

API security focuses specifically on protecting APIs.

A typical API looks like:

API CLIENT
                 |
                 v
        +----------------+
        | API Gateway    |
        +----------------+
                 |
                 v
        +----------------+
        | API Application |
        +----------------+
          |      |      |
          v      v      v
       Database Cache Services

An API can be attacked through:

Authentication
Authorisation
Input
Parameters
Headers
Tokens
Business logic
Rate limits
Data exposure
API configuration

22. REST APIs

REST APIs commonly use endpoints such as:

GET    /api/users
GET    /api/users/123
POST   /api/users
PATCH  /api/users/123
DELETE /api/users/123

A security tester should understand what each endpoint is supposed to do.

Create an endpoint map:

GET /api/users
GET /api/users/{id}
POST /api/users
PATCH /api/users/{id}
DELETE /api/users/{id}

Then ask:

Who can access it?
What data can they access?
What parameters can they control?
What actions can they perform?
What happens if the user changes an ID?

23. GraphQL Security

GraphQL works differently from traditional REST APIs.

A client can request specific data through queries.

Conceptually:

Client
   |
   | GraphQL Query
   v
GraphQL API
   |
   +------> Resolver
   |
   +------> Database

Security concerns can include:

Authorisation
Excessive query depth
Resource exhaustion
Sensitive fields
Introspection exposure
Resolver-level access control
Input validation

A critical point is that authorisation should not exist only at the GraphQL endpoint.

The application must enforce permissions at the appropriate resolver/business-data level.

24. API Authentication

Common API authentication mechanisms include:

API Keys
Session Cookies
JWT
OAuth 2.0
OpenID Connect
mTLS

Do not assume:

Authorization header exists
        =
API is secure

The server still needs to correctly validate the credentials and determine what the authenticated identity is allowed to do.

25. API Keys

An API key might look conceptually like:

X-API-Key: abc123...

The application uses the key to identify or authorise a client.

Security problems can occur if API keys are:

Hardcoded
Exposed in public repositories
Logged
Sent over HTTP
Not rotated
Overprivileged
Never expired

API keys should be treated as secrets when they provide privileged access.

26. OAuth 2.0

OAuth is primarily an authorisation framework.

A simplified flow:

User
 |
 v
Client Application
 |
 v
Authorisation Server
 |
 | Access Token
 v
Client Application
 |
 | API Request + Token
 v
Resource Server

Do not reduce OAuth to:

"OAuth means login."

Authentication and identity are commonly handled alongside OAuth using OpenID Connect, while OAuth itself is fundamentally about delegated authorisation.

27. Rate Limiting

Imagine:

POST /api/login

An attacker repeatedly sends login attempts:

Attempt 1
Attempt 2
Attempt 3
...
Attempt 100000

If there is no effective rate limiting or other abuse protection, automated attacks become much easier.

Rate limiting can be applied based on factors such as:

IP
Account
API key
Session
Device
Endpoint
Application-specific risk

The exact design depends on the application.

28. CORS

CORS means Cross-Origin Resource Sharing.

It controls how browsers handle certain cross-origin requests.

For example:

https://app.example.com
          |
          | request
          v
https://api.example.com

The server can specify which origins are allowed.

A common mistake is assuming:

CORS = Authentication

It is not.

CORS is primarily a browser security mechanism. It does not stop a server-side attacker from sending requests directly to an API.

29. CSRF

CSRF means Cross-Site Request Forgery.

It generally involves tricking a user's browser into making an unwanted request to a site where the user is already authenticated.

Conceptually:

Victim
  |
  | Logged in
  v
Bank Website
Malicious Website
       |
       | Tricks browser into request
       v
Bank Website

Defences can include:

SameSite cookies
CSRF tokens
Origin/Referer validation where appropriate
Proper request design

CSRF is especially relevant to cookie-based authentication.

30. Security Headers

Web applications can use HTTP security headers to reduce certain classes of attacks.

Important examples include:

Content-Security-Policy
Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy
Permissions-Policy

A useful mental model is:

Browser
   |
   | HTTP Response
   v
Security Headers
   |
   v
Browser security controls

Headers are useful defence-in-depth mechanisms, but they cannot compensate for broken server-side authorisation.

31. What a Security Tester Actually Does

A professional web/API security assessment is not simply:

Run Burp
Run Nuclei
Run Nmap
Report everything

A better methodology is:

1. Understand the application
          |
          v
2. Map the attack surface
          |
          v
3. Identify users and roles
          |
          v
4. Map endpoints and parameters
          |
          v
5. Understand authentication
          |
          v
6. Test authorisation
          |
          v
7. Test input handling
          |
          v
8. Test business logic
          |
          v
9. Validate vulnerabilities
          |
          v
10. Document impact
          |
          v
11. Recommend remediation

32. Your First Mental Model for Web Security

Whenever you see an endpoint, think:

ENDPOINT
                   |
        +----------+----------+
        |          |          |
        v          v          v
     WHO?       WHAT?       WHICH?
        |          |          |
 Authentication Authorisation Object
        |          |          |
        +----------+----------+
                   |
                   v
              CAN THEY DO IT?

For example:

PATCH /api/users/123

Ask:

WHO?
Which user is making the request?
WHAT?
What operation are they attempting?
WHICH?
Which user object are they modifying?
AUTHENTICATION?
Are they logged in?
AUTHORISATION?
Are they allowed to modify user 123?
VALIDATION?
Are the submitted fields allowed?
BUSINESS LOGIC?
Does this change make sense for this user's role?

This thought process is more valuable than memorising vulnerability names.

33. Web Security Testing Tools

Once you understand the concepts, tools become useful.

Intercepting Proxy

Burp Suite

Used to:

Capture requests
Modify requests
Replay requests
Inspect responses
Test parameters
Test authentication
Test authorisation

Basic workflow:

Browser
   |
   v
Burp Suite
   |
   v
Application

Reconnaissance Tools

Common tools include:

Subfinder
Amass
httpx
Naabu
Nuclei
ffuf

Use them to discover and assess the attack surface rather than blindly trusting their output.

API Documentation

Look for:

Swagger
OpenAPI
GraphQL schema
API documentation
Mobile application traffic
JavaScript references

These can reveal the API structure.

34. How to Start Testing an API

Suppose you discover:

GET /api/profile
GET /api/users/123
POST /api/orders
PATCH /api/orders/123
DELETE /api/orders/123

Do not immediately start throwing random payloads.

First create a map:

EndpointMethodPurposeAuthenticationAuthorisation/api/profileGETProfileYesUser/api/users/123GETUser dataYesCheck ownership/api/ordersPOSTCreate orderYesUser/api/orders/123PATCHModify orderYesCheck ownership/api/orders/123DELETEDelete orderYesCheck ownership

Then test systematically.

35. The Three Most Important API Questions

For every API endpoint, ask:

1. CAN I ACCESS IT?
2. CAN I ACCESS SOMEONE ELSE'S OBJECT?
3. CAN I PERFORM AN ACTION I SHOULD NOT BE ABLE TO PERFORM?

These three questions uncover a large class of real-world API security issues.

36. Understanding Attack Surface

An application may have:

example.com

But its actual attack surface could include:

www.example.com
api.example.com
admin.example.com
dev.example.com
staging.example.com
cdn.example.com
mobile API
GraphQL API
WebSockets
Cloud storage
Third-party integrations

Therefore:

Domain
  |
  +--> Subdomains
  |
  +--> Applications
  |
  +--> APIs
  |
  +--> Files
  |
  +--> Cloud services
  |
  +--> Third-party integrations

Security testing begins with understanding this attack surface.

37. Authentication Testing Mindset

When testing authentication, think about:

Registration
     |
     v
Login
     |
     v
Session
     |
     v
Password Reset
     |
     v
MFA
     |
     v
Logout

Ask questions such as:

Can authentication be bypassed?
Can accounts be enumerated?
Is password reset secure?
Are sessions invalidated correctly?
Is MFA enforced where required?
Are tokens properly validated?
Can a session be reused after logout?

The objective is to understand the entire authentication lifecycle, not just the login form.

38. Authorisation Testing Mindset

Create multiple identities where authorised for testing.

For example:

User A
User B
Admin

Then compare access:

User A ---> Object A   ✓
User A ---> Object B   ?
User A ---> Admin API  ?
User B ---> Object A   ?
Admin ---> Object A    ✓

This is where BOLA/IDOR and privilege-escalation vulnerabilities are often discovered.

39. Horizontal vs Vertical Privilege Escalation

Horizontal

One normal user accesses another normal user's data.

User A
  |
  X
  v
User B's Data

Vertical

A lower-privileged user performs an administrator-level action.

Normal User
     |
     X
     v
Admin Function

Remember:

Horizontal = same privilege level
Vertical = higher privilege level

40. Input Validation

Every application receives input.

Examples:

Username
Email
Password
Search
ID
Filename
URL
JSON
Headers
Cookies
Query parameters

Security testing asks:

What happens if the input is unexpected?

Examples of unexpected input include:

Very long input
Empty input
Unexpected type
Unexpected characters
Negative values
Large numbers
Duplicate parameters
Missing parameters
Unexpected JSON fields

The correct validation strategy depends on the input and business requirement.

41. Never Trust Client-Side Security

Suppose the browser contains:

if (user.role === "admin") {
    showDeleteButton();
}

Hiding the button does not secure the operation.

An attacker can potentially call the API directly.

Correct architecture:

Browser
   |
   | DELETE /api/user/123
   v
Server
   |
   | Check authentication
   |
   | Check authorisation
   |
   | Check business rules
   |
   v
Database

Security decisions must be enforced on the server.

42. Security Testing vs Vulnerability Scanning

These are not the same.

Scanner

A scanner can help identify:

Known vulnerabilities
Misconfigurations
Exposed technologies
Common patterns

Manual Testing

A human can understand:

Business logic
User roles
Application workflows
Authorisation boundaries
Unexpected behaviour
Complex API interactions

A useful model is:

Automation
    +
Manual Testing
    +
Application Understanding
    =
Better Security Assessment

43. How to Learn This in the Correct Order

Do not start by memorising OWASP vulnerability names.

Use this order:

LEVEL 1
Internet + HTTP
       |
       v
LEVEL 2
HTML + JavaScript basics
       |
       v
LEVEL 3
Web application architecture
       |
       v
LEVEL 4
HTTP requests/responses
       |
       v
LEVEL 5
Cookies + Sessions
       |
       v
LEVEL 6
Authentication
       |
       v
LEVEL 7
Authorisation
       |
       v
LEVEL 8
REST APIs + JSON
       |
       v
LEVEL 9
GraphQL + OAuth/JWT
       |
       v
LEVEL 10
OWASP vulnerabilities
       |
       v
LEVEL 11
Burp Suite + manual testing
       |
       v
LEVEL 12
Business logic + advanced testing

44. Your Web Security Learning Map

WEB SECURITY
                         |
       +-----------------+-----------------+
       |                 |                 |
       v                 v                 v
   FUNDAMENTALS       WEB APP             API
       |                 |                 |
       |                 |                 |
    HTTP              Cookies            REST
    DNS               Sessions            JSON
    TLS               Auth                JWT
    HTML              AuthZ               OAuth
    JS                XSS                 GraphQL
       |                 |                 |
       +-----------------+-----------------+
                         |
                         v
                  VULNERABILITIES
                         |
       +-----------------+-----------------+
       |                 |                 |
       v                 v                 v
   Injection         Access Control    Misconfiguration
       |                 |                 |
       v                 v                 v
    SQLi              IDOR/BOLA          CORS
    XSS               Privilege          Headers
    Command           Escalation         Exposure
                         |
                         v
                   BUSINESS LOGIC
                         |
                         v
                  MANUAL TESTING
                         |
                         v
                  SECURITY REPORT

45. The Security Mindset

A beginner often thinks:

"Which payload should I use?"

A better security tester asks:

"What security assumption is the developer making?"

For example:

Developer assumption:
"The user will only request their own ID."
Tester question:
"What happens if the ID is changed?"

Another:

Developer assumption:
"Only the frontend shows the admin button."
Tester question:
"Does the backend independently enforce admin authorisation?"

Another:

Developer assumption:
"Users will upload images."
Tester question:
"Does the server actually enforce the file requirements?"

This is the transition from tool user to security researcher.

46. What You Should Be Able to Explain

After studying the fundamentals, you should be able to explain these without memorising definitions:

What happens when I open a website?
What is HTTP?
What is HTTPS?
What is a request?
What is a response?
What are cookies?
What is a session?
What is authentication?
What is authorisation?
What is REST?
What is JSON?
What is an API?
What is JWT?
What is OAuth?
What is GraphQL?
What is BOLA/IDOR?
What is XSS?
What is SQL injection?
What is SSRF?
What is CSRF?
What is CORS?
What is rate limiting?
What is business logic?
Why can't the frontend be trusted?
How does Burp Suite help?
How do I test an application systematically?

If you can explain these concepts in your own words and demonstrate them in a legal lab, you have moved beyond simply memorising cybersecurity terminology.

47. A Simple Real-World Mental Model

Imagine an online shopping application.

SHOPPING APP
                      |
        +-------------+-------------+
        |             |             |
        v             v             v
      Login         Products       Orders
        |             |             |
        v             v             v
   Authentication    API          API
        |                           |
        +-------------+-------------+
                      |
                      v
                  Database

Now security testing becomes a series of questions:

LOGIN
 |
 +--> Can authentication be bypassed?
 +--> Is password reset secure?
 +--> Is MFA enforced?
PRODUCTS
 |
 +--> Can hidden products be accessed?
 +--> Can prices be manipulated?
ORDERS
 |
 +--> Can User A access User B's order?
 +--> Can User A modify User B's order?
 +--> Can a normal user perform admin actions?
API
 |
 +--> Are tokens validated?
 +--> Are permissions checked?
 +--> Is sensitive data exposed?
 +--> Is rate limiting implemented?

That is the basic way a professional approaches application security.

48. Final Mental Model

Do not try to remember cybersecurity as a giant list.

Remember this:

USER
                   |
                   v
              APPLICATION
                   |
          +--------+--------+
          |        |        |
          v        v        v
       IDENTITY  DATA     ACTION
          |        |        |
          v        v        v
       Who are   What can  What can
       you?      you see?  you do?
          |        |        |
          +--------+--------+
                   |
                   v
              SECURITY

For every feature, ask:

WHO?
    Who is making the request?
WHAT?
    What are they requesting?
WHICH?
    Which object/data are they accessing?
WHY?
    Are they actually allowed to do it?
HOW?
    Can the request be manipulated?
IMPACT?
    What happens if the security control fails?

That is the foundation of Web Application Security and API Security.

Once this mental model is clear, you can progressively learn OWASP vulnerabilities, Burp Suite, API testing, authentication attacks, authorisation testing, business-logic testing, and advanced application security without treating them as disconnected topics.