APIs are one of the most important components of modern web applications. They connect front-end interfaces with back-end services, handle authentication, process user data, and allow different systems to communicate.

However, APIs also introduce a significant attack surface. An application may appear secure through its graphical interface while exposing undocumented endpoints, accepting unexpected HTTP methods, trusting hidden parameters, or incorrectly processing user-controlled input.

For penetration testers, testing the API directly can reveal vulnerabilities that are difficult or impossible to discover through normal browser interaction.

This article explores API security testing from a penetration testing perspective, covering reconnaissance, endpoint discovery, API documentation, HTTP methods, content types, hidden parameters, mass assignment, Server-Side Parameter Pollution (SSPP), Burp Suite workflows, OWASP API Security, and defensive techniques.

1. Understanding APIs

What Is an API?

An API (Application Programming Interface) is a mechanism that allows different software components to communicate with each other.

In a typical web application, the browser does not necessarily communicate directly with the database. Instead, it sends HTTP requests to an API, which processes the request and communicates with the back-end infrastructure.

A simplified architecture looks like this:

+----------------------+
|      User Browser    |
+----------------------+
           |
           | HTTP Request
           v
+----------------------+
|    Front-End App     |
+----------------------+
           |
           | API Request
           v
+----------------------+
|      API Server      |
+----------------------+
           |
           | Database Query
           v
+----------------------+
|       Database       |
+----------------------+

For example, when a user opens their profile, the application might send:

GET /api/users/123 HTTP/1.1
Host: example.com
Authorization: Bearer <TOKEN>

The API processes the request and returns information about the requested user.

Common API Types

REST API

REST (Representational State Transfer) is an architectural style commonly used with HTTP methods and resource-based URLs.

Example:

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

GraphQL API

GraphQL allows clients to request specific data through a structured query language.

Example:

query {
    user(id: 123) {
        username
        email
    }
}

Unlike traditional REST APIs, GraphQL commonly uses a single endpoint to handle multiple operations.

SOAP API

SOAP (Simple Object Access Protocol) is a messaging protocol that commonly uses XML-based messages and structured service definitions.

This article primarily focuses on RESTful and JSON-based APIs, while also discussing structured-data injection and internal API communication.

2. API Reconnaissance

API reconnaissance is the first stage of API penetration testing.

The objective is to understand how the application communicates with its back-end services and identify as much of the available attack surface as possible.

Before testing vulnerabilities, a penetration tester should identify:

• API endpoints.
• Supported HTTP methods.
• Required and optional parameters.
• Authentication mechanisms.
• Accepted content types.
• API versions.
• Rate limits.
• Exposed documentation.
• Differences between user roles.

2.1 Identifying API Endpoints

An endpoint is a specific URL where an API receives requests for a particular resource or operation.

For example:

GET /api/books

The endpoint is /api/books.

Another endpoint might be:

GET /api/books/123

This could retrieve a specific book.

During reconnaissance, look for URL patterns such as:

/api/
/api/v1/
/api/v2/
/rest/
/graphql
/users/
/admin/
/internal/

These paths are examples of naming conventions, not guaranteed endpoint locations.

2.2 Browse the Application Through Burp Suite

One of the most effective ways to discover API endpoints is to browse the application while Burp Suite intercepts the traffic.

Recommended workflow:

1. Open Burp Suite.
2. Configure the browser to use Burp Proxy.
3. Open the target application.
4. Navigate through different features.
5. Monitor requests in HTTP history.
6. Identify requests containing /api/.
7. Send interesting requests to Repeater.
8. Record discovered endpoints and parameters.

Pay particular attention to:

• Login and registration.
• User profiles.
• Account settings.
• Search functionality.
• File uploads.
• Administrative interfaces.
• Password changes.
• Shopping carts and payment workflows.

A front-end application may communicate with several API endpoints without displaying their URLs directly to the user.

2.3 Inspect JavaScript Files

JavaScript files can reveal API endpoints that have not been accessed through normal browser navigation.

For example:

fetch("/api/v1/account/details");

Or:

axios.get("/api/admin/users");

These references may reveal additional functionality.

Useful approaches include:

• Manually reviewing JavaScript files.
• Using Burp Scanner to crawl the application.
• Using the JS Link Finder Burp extension.
• Searching downloaded JavaScript files for API-related paths.

Remember that discovering an endpoint does not automatically mean that it is vulnerable or accessible.

3. Discovering API Documentation

API documentation explains how developers are expected to interact with an API.

It may contain:

• Available endpoints.
• Supported HTTP methods.
• Required parameters.
• Request formats.
• Response structures.
• Authentication requirements.
• Example requests.

Documentation can be human-readable or machine-readable.

3.1 Human-Readable Documentation

Human-readable documentation explains how to use an API through descriptions and examples.

Common documentation paths include:

/api
/docs
/swagger
/swagger-ui
/swagger/index.html
/api-docs

These are common examples worth checking during authorized reconnaissance.

3.2 Machine-Readable Documentation

Machine-readable documentation allows tools to process API specifications automatically.

Common formats include:

• OpenAPI.
• Swagger.
• JSON.
• YAML.
• XML.

Example OpenAPI-style JSON:

{
  "openapi": "3.0.0",
  "paths": {
    "/api/users": {
      "get": {
        "summary": "Retrieve users"
      },
      "post": {
        "summary": "Create a user"
      }
    }
  }
}

This document reveals that /api/users supports GET and POST operations.

3.3 Analyzing API Documentation

When documentation is discovered, compare its information with the actual application behavior.

Look for:

• Endpoints missing from the visible interface.
• Old API versions.
• Administrative operations.
• Unexpected HTTP methods.
• Optional parameters.
• Sensitive object properties.
• Differences between documented and implemented behavior.

Useful tools include:

ToolPurposeBurp SuiteIntercept and analyze HTTP trafficOpenAPI ParserParse OpenAPI documentationPostmanSend and organize API requestsSoapUITest API servicesBurp RepeaterManually modify requests

An important point: documentation is not always accurate or up to date. Always verify discovered functionality against the actual API.

4. Identifying and Interacting With API Endpoints

After discovering endpoints, the next step is to understand how they behave.

A useful testing approach is to send requests through Burp Repeater and observe the application’s responses.

Consider:

GET /api/tasks HTTP/1.1
Host: example.com

The API might return:

{
  "tasks": [
    {
      "id": 1,
      "title": "Complete security assessment"
    }
  ]
}

Now investigate whether the endpoint supports other operations.

4.1 Understanding HTTP Methods

HTTP methods define the intended operation performed on a resource.

MethodTypical PurposeGETRetrieve informationPOSTCreate a resource or perform an operationPUTReplace a resourcePATCHPartially update a resourceDELETEDelete a resourceOPTIONSDiscover communication options, including supported methods

For example:

GET /api/tasks

Retrieves tasks.

POST /api/tasks
Content-Type: application/json

{
  "title": "New task"
}

Creates a task.

PATCH /api/tasks/1
Content-Type: application/json

{
  "title": "Updated task"
}

Updates part of an existing task.

DELETE /api/tasks/1

Deletes a task.

4.2 Testing Supported HTTP Methods

An API endpoint may support multiple methods, even if the front-end only uses one.

During authorized testing:

1. Capture a legitimate request.
2. Send it to Burp Repeater.
3. Change the HTTP method.
4. Observe the response.
5. Compare status codes and response bodies.
6. Document any unexpected functionality.

The OPTIONS method may also provide information about supported methods:

OPTIONS /api/tasks HTTP/1.1
Host: example.com

A response might contain:

Allow: GET, POST, OPTIONS

This is useful reconnaissance information, although the Allow header is not always a complete or reliable representation of the server's actual behavior.

Important: Test state-changing methods only against authorized test resources. Use low-impact objects to avoid unintended modifications or deletions.

4.3 Identifying Supported Content Types

An API may accept different request formats.

Common content types include:

JSON

Content-Type: application/json

Example:

{
  "username": "testuser",
  "email": "test@example.com"
}

URL-Encoded Form Data

Content-Type: application/x-www-form-urlencoded

Example:

username=testuser&email=test%40example.com

Multipart Form Data

Content-Type: multipart/form-data; boundary=----Boundary123

Commonly used for forms containing file uploads.

XML

Content-Type: application/xml

Example:

<user>
    <username>testuser</username>
    <email>test@example.com</email>
</user>

Why Does Content-Type Matter?

Different content types can be processed by different parsers and application components.

This may introduce inconsistent security behavior.

For example:

• JSON requests may be validated correctly.
• XML requests may follow a different processing path.
• Form data may be handled by another parser.
• Unexpected formats may trigger informative error messages.

A tester should determine which formats are actually supported and whether validation is consistent across them.

In Burp Suite, modify the Content-Type header and ensure that the body matches the selected format.

Burp’s Content Type Converter extension can help convert request bodies between supported formats.

5. Discovering Hidden API Endpoints

Not every API endpoint is linked from the application’s front-end.

Some endpoints may exist for administrative operations, internal features, legacy functionality, or mobile applications.

For example, you might discover:

PUT /api/user/update

However, other operations could exist under similar naming conventions.

Potential naming patterns include:

/api/user/update
/api/user/delete
/api/user/create
/api/user/export
/api/user/search

These are illustrative examples.

5.1 Using Burp Intruder

Burp Intruder can automate endpoint discovery by replacing a selected part of a request with values from a wordlist.

A basic workflow:

1. Capture an existing API request.
2. Send it to Intruder.
3. Select the endpoint operation as the payload position.
4. Load a suitable API endpoint wordlist.
5. Start the authorized test.
6. Compare response status codes, lengths, and content.

For example, the request:

PUT /api/user/update

can be used as a starting point for discovering related operations.

5.2 Interpreting Responses

Pay attention to differences such as:

ResponsePossible Meaning200 OKRequest processed successfully201 CreatedResource created204 No ContentSuccessful operation without response body400 Bad RequestInvalid request401 UnauthorizedAuthentication required or invalid403 ForbiddenAccess denied404 Not FoundResource or route not found405 Method Not AllowedHTTP method unsupported

These responses are clues, not definitive vulnerability indicators.

A 403 response does not prove that an endpoint is secure, and a 404 response does not always prove that a route does not exist.

6. Finding Hidden API Parameters

An API may accept parameters that are not documented or displayed in the front-end.

These parameters may influence application behavior.

For example:

GET /api/users?id=123

The application visibly uses only the id parameter.

However, additional parameters might be supported internally.

Potential examples include:

role
isAdmin
status
debug
email
access_level

These are examples of parameter names, not evidence that a particular application supports them.

6.1 Burp Intruder

Burp Intruder can help discover undocumented parameters by testing candidate parameter names.

For example:

GET /api/users?id=123&§parameter§=test

A wordlist is inserted into the selected position.

Compare responses to identify parameters that influence application behavior.

6.2 Param Miner

Param Miner is a Burp Suite extension designed to discover hidden parameters and headers.

It can automatically guess parameter names using information gathered from the application.

It is especially useful when manually testing a large number of potential parameters would be inefficient.

6.3 Content Discovery

Burp’s Content Discovery functionality can help identify resources that are not directly linked from the application’s visible pages.

This can reveal additional paths and functionality that should be included in the API attack surface assessment.

7. Mass Assignment Vulnerabilities

Mass Assignment is a vulnerability that occurs when an application automatically binds user-supplied request parameters to internal objects without properly restricting which properties users are allowed to modify.

It is also known as:

• Auto-binding.
• Automatic parameter binding.

7.1 Understanding the Root Cause

Consider an application that allows users to update their profiles.

The front-end sends:

PATCH /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "username": "wiener",
  "email": "wiener@example.com"
}

The server processes these properties and updates the corresponding user object.

Internally, the user object may contain additional properties:

{
  "id": 123,
  "username": "wiener",
  "email": "wiener@example.com",
  "isAdmin": false,
  "accountStatus": "active"
}

The problem occurs when the application automatically binds every submitted property to the internal object.

Instead of allowing only username and email, it might also accept properties such as isAdmin.

7.2 Identifying Hidden Properties

A tester can compare the properties returned by a GET request with the properties accepted by a legitimate update operation.

For example:

GET request:

GET /api/users/123

Response:

{
  "id": 123,
  "username": "wiener",
  "email": "wiener@example.com",
  "isAdmin": false
}

Normal PATCH request:

{
  "username": "wiener",
  "email": "wiener@example.com"
}

The response reveals that the user object contains an isAdmin property, even though the normal update interface does not expose it.

This creates a testing hypothesis: perhaps the API accepts properties that the front-end does not allow users to modify.

7.3 Testing Mass Assignment

In an authorized lab, a tester can compare how the application handles an additional property.

For example:

{
  "username": "wiener",
  "email": "wiener@example.com",
  "isAdmin": "invalid"
}

Then compare it with a valid Boolean value:

{
  "username": "wiener",
  "email": "wiener@example.com",
  "isAdmin": true
}

Observe:

• Response status.
• Response body.
• Error messages.
• Whether the property changes.
• Whether the change persists.
• Whether the application’s authorization behavior changes.

A different response to an invalid value can provide evidence that the property is being processed.

However, response differences alone do not confirm exploitation. The actual server-side state and authorization behavior must be verified.

7.4 Security Impact

Successful mass assignment can result in:

• Unauthorized privilege changes.
• Account manipulation.
• Modification of protected properties.
• Changes to account status.
• Unauthorized access to administrative functionality.

The impact depends on which internal properties are exposed and how the application uses them.

7.5 Prevention

Developers should:

1. Use explicit allowlists of properties that users can update.
2. Never bind untrusted request data directly to sensitive internal objects.
3. Apply server-side authorization to sensitive properties.
4. Validate property types and values.
5. Separate public user models from internal database models.

A secure update operation should explicitly select permitted properties instead of accepting arbitrary fields.

8. Server-Side Parameter Pollution (SSPP)

Server-Side Parameter Pollution occurs when an application inserts user-controlled input into a server-side request without correctly encoding or validating it.

This is particularly important when an application communicates with internal APIs.

8.1 Understanding the Architecture

Consider the following architecture:

+----------------------+
|      User Browser    |
+----------------------+
           |
           | User Request
           v
+----------------------+
|    Public Website    |
+----------------------+
           |
           | Internal API Request
           v
+----------------------+
|     Internal API     |
+----------------------+
           |
           v
+----------------------+
|       Database       |
+----------------------+

The user cannot directly access the internal API.

However, the public website sends requests to that API on the user’s behalf.

If user input is inserted into those requests without proper encoding, the user may be able to manipulate the resulting request.

Potential impacts include:

• Overriding existing parameters.
• Changing internal API behavior.
• Accessing unauthorized data.
• Manipulating structured request data.

8.2 Testing Query String Pollution

Consider a public endpoint:

GET /userSearch?name=peter&back=/home

The application internally constructs:

GET /users/search?name=peter&publicProfile=true

The important detail is that the public application is generating a second request.

If the name parameter is not encoded correctly, special query characters may affect the internal request.

8.3 Query String Truncation

A URL-encoded # character can potentially cause the remainder of an internal URL to be interpreted as a fragment.

For example, in an authorized test:

GET /userSearch?name=peter%23foo&back=/home

The application may construct:

GET /users/search?name=peter#foo&publicProfile=true

In URL processing, the fragment begins at # and is not normally sent as part of an HTTP request target.

This could effectively remove the remaining query string from the internal request.

The result may change how the internal API processes the request.

Important: The # must be URL-encoded in the original request so that the browser or HTTP client does not interpret it as a client-side fragment before sending it.

8.4 Injecting Additional Parameters

An encoded ampersand may introduce another parameter into a poorly constructed internal query string.

Example:

GET /userSearch?name=peter%26foo=xyz&back=/home

The internal application might generate:

GET /users/search?name=peter&foo=xyz&publicProfile=true

If the internal API ignores the unknown parameter, the response may remain unchanged.

This does not necessarily mean the injection failed. It may simply indicate that the parameter has no effect.

8.5 Injecting Valid Parameters

If a tester identifies a parameter that the internal API recognizes, it may be possible to influence its behavior.

For example, suppose the internal API accepts an email parameter.

A test request could introduce that parameter through user-controlled input:

GET /userSearch?name=peter%26email=test&back=/home

The resulting internal request could resemble:

GET /users/search?name=peter&email=test&publicProfile=true

The response should be compared with a normal request to determine whether the additional parameter is being processed.

8.6 Overriding Existing Parameters

One important SSPP test is determining how an internal API handles duplicate parameters.

For example:

GET /userSearch?name=peter%26name=carlos&back=/home

The internal request may become:

GET /users/search?name=peter&name=carlos&publicProfile=true

Different technologies may process duplicate parameters differently.

Technology / Parser BehaviorPossible ResultPHPCommonly uses the last scalar valueNode.js / ExpressCommonly uses the first scalar valueASP.NETMay combine repeated values

Actual behavior depends on the framework, parser configuration, and application code.

This difference is important because the public application and internal API may interpret duplicate parameters differently.

8.7 Testing REST Path Pollution

SSPP is not limited to query strings.

Some APIs place resource identifiers directly inside URL paths.

For example:

/api/users/123

The URL can be interpreted as:

/api       -> API root
/users     -> Resource
/123       -> Resource identifier

Consider a public request:

GET /edit_profile.php?name=peter

The application internally generates:

GET /api/private/users/peter

If the input is not correctly encoded, path manipulation may affect the internal resource path.

For example:

GET /edit_profile.php?name=peter%2f..%2fadmin

The internal request may resemble:

/api/private/users/peter/../admin

If the server normalizes the path, it could resolve to a different resource.

This demonstrates why server-side URL construction must use proper encoding and strict validation.

8.8 Testing Structured Data Pollution

SSPP can also affect structured formats such as JSON and XML.

Consider a public application that allows users to update their names.

The browser sends:

POST /myaccount
Content-Type: application/x-www-form-urlencoded

name=peter

The server internally creates:

PATCH /users/7312/update
Content-Type: application/json

{
  "name": "peter"
}

If the server inserts user input directly into the JSON string instead of using a proper JSON serializer, special characters may alter the resulting structure.

The security problem is not JSON itself. It is unsafe construction of structured data using untrusted strings.

The same principle applies when JSON data is built from user-controlled input.

Key distinction: Properly parsing and serializing JSON is fundamentally different from concatenating raw strings to construct JSON documents.

8.9 Automated SSPP Testing

Burp Suite can assist with identifying suspicious input transformations.

Useful approaches include:

• Burp Scanner audits.
• Manual testing through Repeater.
• Backslash Powered Scanner.
• Comparing normal and modified responses.

Automated findings should always be manually verified.

A suspicious transformation does not automatically establish a vulnerability.

8.10 Preventing SSPP

Developers should:

• Properly encode all user-controlled input.
• Use structured URL-building libraries.
• Avoid constructing internal requests through string concatenation.
• Validate input against expected formats.
• Use parameterized interfaces where applicable.
• Reject unexpected characters when they are not part of the intended input.
• Ensure that internal APIs independently enforce authorization.

9. API Security Testing Workflow With Burp Suite

A structured workflow makes API testing more effective and helps prevent missed functionality.

Phase 1: Reconnaissance

Objective: Understand the application and discover its API attack surface.

Activities:

• Browse the application through Burp Proxy.
• Identify API-related requests.
• Review JavaScript files.
• Identify API versions.
• Search for exposed documentation.
• Record discovered endpoints.

Phase 2: Endpoint Enumeration

Objective: Discover additional API functionality.

Activities:

• Examine URL patterns.
• Review undocumented paths.
• Use authorized content discovery.
• Use Intruder to test candidate endpoint names.
• Compare responses.

Phase 3: HTTP Method Testing

Objective: Determine which operations each endpoint supports.

Activities:

• Test relevant HTTP methods.
• Review OPTIONS responses.
• Identify unexpected functionality.
• Compare application behavior.

Phase 4: Content-Type Testing

Objective: Understand how the API processes different request formats.

Activities:

• Identify the expected content type.
• Review JSON and form-data handling.
• Test other supported formats.
• Examine parser errors.
• Compare validation behavior.

Phase 5: Hidden Parameter Discovery

Objective: Identify undocumented parameters and sensitive object properties.

Activities:

• Examine API responses.
• Compare GET and PATCH requests.
• Use Param Miner.
• Review hidden object fields.
• Investigate unexpected behavior.

Phase 6: Authorization Testing

Objective: Verify that API operations enforce the correct permissions.

Activities:

• Compare access between authorized test accounts.
• Check object-level authorization.
• Check function-level authorization.
• Verify access to sensitive properties.
• Test whether server-side permissions match the application’s intended access model.

Phase 7: Injection and Parameter Pollution

Objective: Determine whether untrusted input can influence server-side processing.

Activities:

• Review how parameters are transformed.
• Inspect internal request behavior where observable.
• Test query-string handling.
• Review path construction.
• Examine structured-data processing.

Phase 8: Verification and Reporting

Objective: Confirm findings and document their security impact.

For every finding, record:

• Vulnerability title.
• Affected endpoint.
• Preconditions.
• Reproduction steps.
• Evidence.
• Security impact.
• Recommended remediation.

10. OWASP API Security Top 10 (2023)

The OWASP API Security Top 10 identifies major security risks affecting APIs.

Understanding these categories helps penetration testers build a broader testing methodology.

IDVulnerabilityDescriptionAPI1Broken Object Level Authorization (BOLA)Users can access objects they are not authorized to access.API2Broken AuthenticationAuthentication mechanisms can be bypassed or abused.API3Broken Object Property Level AuthorizationUnauthorized access to or modification of sensitive object properties.API4Unrestricted Resource ConsumptionAPIs lack sufficient controls over resource usage.API5Broken Function Level AuthorizationUsers can access functions beyond their permissions.API6Unrestricted Access to Sensitive Business FlowsSensitive business operations lack adequate protection.API7Server-Side Request Forgery (SSRF)Server-side requests can be manipulated to reach unintended destinations.API8Security MisconfigurationInsecure configurations expose the API to attacks.API9Improper Inventory ManagementOld, undocumented, or forgotten API versions remain exposed.API10Unsafe Consumption of APIsApplications do not safely validate or process responses from external APIs.

How API Testing Relates to These Risks

API reconnaissance helps identify undocumented versions and endpoints.

Authorization testing helps discover BOLA and BFLA vulnerabilities.

Mass assignment testing is particularly relevant to object property authorization.

Resource and rate-limit testing helps assess unrestricted resource consumption.

SSRF testing examines whether APIs can be abused to make unintended server-side requests.

This demonstrates that API security testing is not limited to finding hidden endpoints. It requires understanding the complete security model of the application.

11. API Security Best Practices

API security should be implemented at the application and infrastructure levels.

Authentication and Authorization

• Require authentication for protected operations.
• Enforce authorization on every request.
• Verify ownership of requested resources.
• Apply role-based or attribute-based access controls where appropriate.
• Never rely exclusively on front-end restrictions.

Input Validation

• Validate all user-controlled input.
• Enforce expected data types.
• Validate request structures.
• Use safe parsers and serializers.
• Reject unexpected properties where appropriate.

HTTP Method Restrictions

• Allowlist supported HTTP methods.
• Disable unnecessary operations.
• Apply authorization independently to every method.

Content-Type Validation

• Validate incoming content types.
• Use appropriate parsers.
• Avoid inconsistent validation between formats.

Mass Assignment Protection

• Allowlist user-editable properties.
• Separate internal models from public API models.
• Protect administrative and security-sensitive fields.

SSPP Protection

• Encode input before including it in server-side requests.
• Avoid string concatenation when constructing URLs and structured data.
• Use safe URL-building libraries.
• Validate internal request parameters.

Error Handling

• Avoid exposing internal stack traces.
• Do not reveal sensitive database information.
• Use appropriate error messages.
• Log useful security events internally.

API Version Management

• Maintain an inventory of active API versions.
• Remove unsupported versions.
• Apply security controls consistently.
• Avoid exposing unnecessary internal documentation.

12. Practical API Testing Checklist

The following checklist can be used during an authorized web application penetration test.

Reconnaissance

• Identify API endpoints.
• Review JavaScript files.
• Identify API versions.
• Locate API documentation.
• Understand authentication requirements.

Endpoint Testing

• Identify supported HTTP methods.
• Review OPTIONS responses.
• Test relevant content types.
• Search for undocumented endpoints.
• Review error messages.

Parameter Testing

• Identify required parameters.
• Identify optional parameters.
• Search for hidden parameters.
• Review returned object properties.
• Test mass assignment safely.

Authorization

• Test object-level authorization.
• Test function-level authorization.
• Review sensitive properties.
• Compare behavior across authorized test accounts.

Server-Side Parameter Pollution

• Review query-string construction.
• Investigate parameter truncation.
• Investigate additional parameter injection.
• Review duplicate parameter handling.
• Examine REST path construction.
• Review structured-data processing.

Reporting

• Verify findings.
• Record affected endpoints.
• Capture relevant HTTP requests and responses.
• Explain the security impact.
• Provide remediation recommendations.

13. Conclusion

API security testing is an essential part of modern web application penetration testing.

A web application may expose only a small portion of its functionality through the front-end, while its API provides additional operations, parameters, and resources that require independent security assessment.

Understanding API architecture, performing effective reconnaissance, identifying hidden endpoints, testing HTTP methods, examining content types, and discovering undocumented parameters can reveal weaknesses that ordinary browser testing may overlook.

Mass assignment demonstrates the risks of automatically binding user input to internal objects, while Server-Side Parameter Pollution highlights the dangers of constructing internal requests from untrusted data.

Most importantly, successful API testing requires more than sending unusual requests. It requires understanding how the application processes input, enforces authorization, communicates with internal services, and protects sensitive operations.

The key principle is simple: never assume that an API is secure just because its front-end interface appears restricted. Every exposed endpoint, method, parameter, and object property should be evaluated within the application’s intended security model.

References and Further Reading

1. PortSwigger Web Security Academy — API Testing
2. PortSwigger — Server-Side Parameter Pollution
3. PortSwigger — Access Control Vulnerabilities
4. PortSwigger — GraphQL API Vulnerabilities
5. OWASP API Security Top 10–2023
6. OpenAPI Specification
7. Burp Suite Documentation

Disclaimer: This article is intended for educational purposes and authorized security testing. Only assess systems for which you have explicit permission.

Introduction

GraphQL has become a popular technology for building APIs because it gives clients more control over the data they request. Instead of interacting with multiple endpoints, clients can use a single GraphQL endpoint to retrieve or modify different types of data.

However, this flexibility introduces security challenges.

GraphQL vulnerabilities generally arise from implementation and design flaws rather than from the GraphQL language itself. Incorrect authorization checks, excessive information disclosure, weak input validation, and inadequate resource controls can expose sensitive information or allow unauthorized operations.

For web penetration testers, understanding how GraphQL works is essential before attempting to identify vulnerabilities.

In this article, we will explore the fundamentals of GraphQL, understand its internal structure, and examine common security weaknesses, including:

• Insecure Direct Object References (IDOR).
• Information Disclosure through Introspection.
• Schema Enumeration through Suggestions.
• Introspection Defense Bypasses.
• Rate Limiting Bypasses using Aliases.
• Cross-Site Request Forgery (CSRF).

We will also examine how to investigate these issues using Burp Suite and how developers can prevent them.

1. Understanding GraphQL

1.1 What is GraphQL?

GraphQL is a query language for APIs and a runtime for executing those queries using a defined schema.

It allows clients to request exactly the information they need instead of receiving a predefined response containing unnecessary fields.

Consider an application that stores the following user information:

{
  "id": 1,
  "username": "alex",
  "email": "alex@example.com",
  "age": 22,
  "address": "Morocco"
}

If the client only needs the username and email, it can send the following GraphQL query:

query {
  user(id: 1) {
    username
    email
  }
}

The server might return:

{
  "data": {
    "user": {
      "username": "alex",
      "email": "alex@example.com"
    }
  }
}

Notice that the response contains only the requested fields.

This is one of the main advantages of GraphQL: clients control the structure of the requested data.

An important distinction is that GraphQL does not necessarily communicate directly with a database. Instead, GraphQL resolvers process requests and interact with databases, internal services, or other data sources.

1.2 GraphQL vs REST API

REST and GraphQL approach API communication differently.

In a traditional REST API, different resources usually have different endpoints:

GET /api/users/1
GET /api/users/1/orders
GET /api/users/1/profile

Each endpoint provides access to a particular resource or operation.

GraphQL usually uses a single endpoint:

POST /graphql

The GraphQL query inside the request determines what the server should execute.

For example:

query {
  user(id: 1) {
    name
    email
    orders {
      id
      total
    }
  }
}

A single request can retrieve information about a user and their associated orders.

This difference is particularly important during security testing.

In REST, penetration testers often discover multiple endpoints. In GraphQL, discovering the main endpoint can reveal access to a much larger collection of operations.

1.3 GraphQL Architecture

A typical GraphQL request follows this process:

1. The client sends a GraphQL operation.
2. The GraphQL server parses the request.
3. The server validates the operation against the schema.
4. The appropriate resolvers execute.
5. Resolvers retrieve or modify the required data.
6. The server constructs a response based on the requested selection set.

The following components are important:

Client: The application or browser sending GraphQL requests.

Endpoint: The HTTP endpoint receiving GraphQL operations.

Schema: Defines the available types, fields, operations, and arguments.

Resolvers: Functions responsible for retrieving or modifying data.

Data Sources: Databases, internal APIs, or other services used by resolvers.

From a security perspective, resolvers deserve particular attention because they frequently contain the business logic and authorization decisions.

2. Understanding the GraphQL Schema

2.1 What is a Schema?

A GraphQL schema defines the structure of an API and describes which operations clients are allowed to request.

Think of it as a contract between the client and the server.

For example:

type User {
  id: ID!
  name: String!
  email: String!
}

type Product {
  id: ID!
  name: String!
  price: Float!
}

This schema defines two object types:

• User
• Product

Each type contains fields describing the information available on that object.

2.2 Types and Fields

A Type represents a particular structure of data.

A Field represents an individual piece of information inside that structure.

For example:

type User {
  id: ID!
  name: String!
  email: String!
}

Here:

• User is the Object Type.
• id is a Field.
• name is a Field.
• email is a Field.

GraphQL supports several types:

Scalar Types

These represent basic values:

• String
• Int
• Float
• Boolean
• ID

Enum Types

Enums restrict a field to a predefined set of values.

enum OrderStatus {
  PENDING
  PAID
  CANCELLED
}

Object Types

Objects contain multiple fields.

type Product {
  id: ID!
  name: String!
}

Union Types

A Union allows a field to return one of several object types.

union SearchResult = User | Product

Interface Types

An Interface defines common fields that multiple object types must implement.

interface Animal {
  name: String!
}

type Dog implements Animal {
  name: String!
  breed: String!
}

type Cat implements Animal {
  name: String!
  color: String!
}

2.3 Understanding the Exclamation Mark (!)

In GraphQL, ! indicates that a value is non-nullable.

For example:

type Product {
  id: ID!
  name: String!
  price: Float
}

The difference is:

• id: ID! must have a value.
• name: String! must have a value.
• price: Float can be null.

This is important when understanding the expected input and output types of an API.

2.4 Root Types

GraphQL schemas define root operation types.

The main three are:

• Query
• Mutation
• Subscription

A schema must define a Query root type.

Example:

type Query {
  user(id: ID!): User
  product(id: ID!): Product
  products: [Product]
}

This tells us which read operations are available.

A schema may also define mutations:

type Mutation {
  createProduct(name: String!): Product
  deleteProduct(id: ID!): Boolean
}

3. Understanding GraphQL Operations

GraphQL has three primary operation types.

3.1 Queries

A Query retrieves information without intentionally modifying application state.

Example:

query {
  getProduct(id: 123) {
    name
    description
  }
}

The server executes the corresponding resolver and returns the requested information.

From a penetration testing perspective, Queries are particularly interesting when they expose sensitive objects through user-controlled arguments.

3.2 Mutations

Mutations perform operations that modify application data.

They are commonly used for:

• Creating records.
• Updating information.
• Deleting resources.
• Changing account settings.

Example:

mutation {
  updateUser(id: 1, name: "Ali") {
    id
    name
  }
}

A successful mutation might return:

{
  "data": {
    "updateUser": {
      "id": 1,
      "name": "Ali"
    }
  }
}

Security testing should focus on whether the server verifies that the authenticated user is authorized to perform the requested modification.

3.3 Subscriptions

Subscriptions allow clients to receive real-time updates from the server.

Unlike ordinary Queries, which return a response to a request, Subscriptions establish a longer-lived communication mechanism.

Example:

subscription {
  newMessage {
    id
    content
    sender
  }
}

When a new message is published, the server can send an update to connected clients.

Subscriptions are commonly implemented using WebSockets, although other transports, such as Server-Sent Events, are possible.

Security considerations

Subscriptions introduce additional security concerns:

• Authentication during connection establishment.
• Authorization for individual subscription events.
• Access to private rooms or channels.
• Connection limits.
• Resource consumption.
• Sensitive information exposure.

For example, a user should not be able to subscribe to messages from a private room simply by changing its identifier.

The server must verify room membership independently of the supplied GraphQL arguments.

4. Understanding GraphQL Query Components

Before testing GraphQL vulnerabilities, it is important to understand how individual query components work.

4.1 Fields

Fields represent the information requested from an object.

Example:

query {
  getEmployees {
    id
    name
    email
  }
}

The client requests three fields:

• id
• name
• email

GraphQL can also return nested objects.

query {
  getEmployees {
    id
    name {
      firstname
      lastname
    }
  }
}

Here, name is an object containing two additional fields.

This structure is called a nested selection set.

4.2 Arguments

Arguments provide values to fields and help determine which data the server should return.

Example:

query {
  getEmployee(id: 1) {
    name
    email
  }
}

Here:

• getEmployee is the field.
• id is the argument name.
• 1 is the argument value.

Arguments become particularly important during authorization testing.

If an application relies on an object ID without verifying the user’s permissions, an attacker may be able to access another user’s information.

4.3 Variables

Variables allow clients to provide dynamic values without rewriting the query itself.

Instead of:

query {
  getEmployee(id: 1) {
    name
  }
}

We can write:

query getEmployee($id: ID!) {
  getEmployee(id: $id) {
    name
  }
}

The variable value is provided separately:

{
  "id": 1
}

A complete HTTP request might look like this:

POST /graphql HTTP/1.1
Host: example.local
Content-Type: application/json

{
  "query": "query getEmployee($id: ID!) { getEmployee(id: $id) { name } }",
  "variables": {
    "id": 1
  }
}

Variables improve query reusability, but they are not security controls.

The server must still validate their values and enforce authorization.

4.4 Aliases

Aliases allow clients to assign alternative names to fields in the response.

They are useful when requesting the same field multiple times with different arguments.

Without aliases, the following query creates a field conflict:

query {
  getProduct(id: 1) {
    name
  }

  getProduct(id: 2) {
    name
  }
}

The solution is to use aliases:

query {
  product1: getProduct(id: 1) {
    id
    name
  }

  product2: getProduct(id: 2) {
    id
    name
  }
}

The response will contain two separate properties:

{
  "data": {
    "product1": {
      "id": 1,
      "name": "Product 1"
    },
    "product2": {
      "id": 2,
      "name": "Product 2"
    }
  }
}

Aliases have important security implications, especially when rate limiting is implemented incorrectly.

We will examine this later.

4.5 Fragments

Fragments are reusable sections of GraphQL queries.

They help avoid repeating the same fields across multiple operations.

Example:

fragment productInfo on Product {
  id
  name
  price
}

We can reuse this fragment:

query {
  getProduct(id: 1) {
    ...productInfo
  }
}

The ...productInfo syntax tells GraphQL to include the fields defined inside the fragment.

From a security testing perspective, remember that sensitive fields may appear inside nested objects or fragments, not only in the top-level query.

5. Finding GraphQL Endpoints

Endpoint discovery is the first practical step in GraphQL penetration testing.

Unlike REST APIs, GraphQL services commonly expose their operations through a single endpoint.

For example:

https://example.com/graphql

However, the endpoint name is not always obvious.

5.1 Universal Queries

GraphQL provides a reserved field called __typename.

It returns the name of the current object type.

A simple query is:

query {
  __typename
}

A shorter version is:

{ __typename }

A GraphQL endpoint may respond with:

{
  "data": {
    "__typename": "Query"
  }
}

This is known as a universal query because it can help determine whether a particular endpoint is a GraphQL service.

5.2 Common Endpoint Names

During authorized reconnaissance, common endpoint paths include:

/graphql
/api
/api/graphql
/graphql/api
/graphql/graphql

Some applications also use versioned endpoints:

/graphql/v1
/api/v1/graphql

These paths are useful starting points, not a complete list.

5.3 HTTP Request Methods

GraphQL implementations commonly accept POST requests.

However, some also support GET or POST requests with alternative content types.

The three important request formats to understand are:

POST with application/json

POST /graphql HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "query": "{ __typename }"
}

POST with application/x-www-form-urlencoded

POST /graphql HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

query={__typename}

GET

GET /graphql?query=%7B__typename%7D HTTP/1.1
Host: example.com

The difference is where and how the query is transmitted.

• JSON requests place the query inside a JSON body.
• Form URL-encoded requests place it inside form parameters.
• GET requests commonly place it inside the URL.

The supported methods depend on the server implementation.

5.4 Initial Testing with Burp Suite

Once you identify a possible endpoint:

1. Open the application using Burp’s browser.
2. Browse through its functionality.
3. Open Proxy → HTTP history.
4. Search for requests containing GraphQL operations.
5. Send interesting requests to Repeater.
6. Examine their fields, arguments, variables, and responses.

Do not immediately assume that finding a GraphQL endpoint means a vulnerability exists.

The objective at this stage is to understand how the application communicates with its API.

6. Exploiting Unsanitized Arguments: GraphQL IDOR

One of the most important GraphQL security issues is Broken Access Control.

An API may use arguments to retrieve objects directly from a database.

If the server does not verify whether the authenticated user is authorized to access the requested object, this can result in an IDOR vulnerability.

6.1 Understanding the Scenario

Imagine an online shop that contains several products.

The application only displays products where:

listed = true

The client sends:

query {
  products {
    id
    name
    listed
  }
}

The server returns:

{
  "data": {
    "products": [
      {
        "id": 1,
        "name": "Product 1",
        "listed": true
      },
      {
        "id": 2,
        "name": "Product 2",
        "listed": true
      },
      {
        "id": 4,
        "name": "Product 4",
        "listed": true
      }
    ]
  }
}

Notice that product ID 3 is missing.

This does not prove that the product exists or that it is vulnerable, but it gives us a useful testing hypothesis.

The API might contain a separate field that retrieves individual products:

query {
  product(id: 3) {
    id
    name
    listed
  }
}

Suppose the response is:

{
  "data": {
    "product": {
      "id": 3,
      "name": "Product 3",
      "listed": false
    }
  }
}

The application returned a product that was not included in the original public list.

6.2 Root Cause

The underlying problem is inconsistent authorization or filtering between two resolvers.

The products resolver applies the publication filter, but the product(id) resolver does not enforce the same access restrictions.

The issue is not caused by GraphQL arguments themselves.

It is caused by missing server-side authorization.

6.3 Burp Suite Testing Methodology

Target component: GraphQL query arguments.

Start with the normal request:

POST /graphql HTTP/1.1
Host: example.local
Content-Type: application/json

{
  "query": "{ products { id name listed } }"
}

Then identify individual-object queries and their arguments.

In an authorized test environment:

1. Capture the normal request.
2. Send it to Repeater.
3. Identify object identifiers and related arguments.
4. Compare the behavior of list and individual-object resolvers.
5. Verify whether access restrictions are consistently enforced.
6. Record the response and the impact.

A valid IDOR finding requires demonstrating unauthorized access, not merely changing an ID and receiving a different response.

6.4 Potential Impact

Depending on the application, GraphQL IDOR vulnerabilities can expose:

• Private user information.
• Internal product information.
• Unpublished records.
• Private messages.
• Orders and transaction details.
• Administrative resources.

The severity depends on the sensitivity of the exposed data and the actions available to the user.

7. Discovering GraphQL Schema Information

Understanding the schema is one of the most valuable parts of GraphQL reconnaissance.

There are two important techniques:

1. Introspection.
2. Suggestions.

7.1 What is Introspection?

Introspection is a built-in GraphQL feature that allows clients to query information about the API’s own schema.

It can reveal:

• Available Types.
• Fields.
• Queries.
• Mutations.
• Subscriptions.
• Arguments.
• Data types.
• Descriptions.
• Deprecated fields.

For a penetration tester, this information can provide a detailed overview of the API’s available functionality.

7.2 Important Introspection Fields

GraphQL provides several special fields:

FieldPurpose__schemaReturns information about the schema__typeReturns information about a specific type__typenameReturns the current object's type name

For example:

query {
  __schema {
    queryType {
      name
    }
  }
}

The response might be:

{
  "data": {
    "__schema": {
      "queryType": {
        "name": "Query"
      }
    }
  }
}

7.3 Discovering Mutations

You can also request the available mutation names:

query {
  __schema {
    mutationType {
      fields {
        name
      }
    }
  }
}

A response might reveal:

{
  "data": {
    "__schema": {
      "mutationType": {
        "fields": [
          {
            "name": "createProduct"
          },
          {
            "name": "updateProduct"
          },
          {
            "name": "deleteProduct"
          }
        ]
      }
    }
  }
}

This provides an overview of the available mutation operations.

However, knowing that a mutation exists does not mean that every user can execute it.

Authorization must still be enforced by the server.

7.4 Running a Full Introspection Query

A full introspection query can retrieve extensive information about the schema.

It may include:

• Root operation types.
• Object types.
• Input types.
• Fields.
• Arguments.
• Interfaces.
• Unions.
• Enums.
• Descriptions.
• Deprecation information.

The following is a commonly used introspection query:

query IntrospectionQuery {
  __schema {
    queryType {
      name
    }
    mutationType {
      name
    }
    subscriptionType {
      name
    }
    types {
      ...FullType
    }
    directives {
      name
      description
      args {
        ...InputValue
      }
    }
  }
}

fragment FullType on __Type {
  kind
  name
  description
  fields(includeDeprecated: true) {
    name
    description
    args {
      ...InputValue
    }
    type {
      ...TypeRef
    }
    isDeprecated
    deprecationReason
  }
  inputFields {
    ...InputValue
  }
  interfaces {
    ...TypeRef
  }
  enumValues(includeDeprecated: true) {
    name
    description
    isDeprecated
    deprecationReason
  }
  possibleTypes {
    ...TypeRef
  }
}

fragment InputValue on __InputValue {
  name
  description
  type {
    ...TypeRef
  }
  defaultValue
}

fragment TypeRef on __Type {
  kind
  name
  ofType {
    kind
    name
    ofType {
      kind
      name
      ofType {
        kind
        name
      }
    }
  }
}

Some implementations may require adjustments to introspection queries depending on the supported schema features.

7.5 Visualizing Introspection Results

Full introspection responses can be extremely large.

Reading the entire JSON response manually can become difficult, especially when the API contains many interconnected types.

A GraphQL visualizer can help transform the returned schema into a visual representation.

For example:

Query
 ├── products
 │    └── Product
 │         ├── id
 │         ├── name
 │         └── price
 │
 └── product(id)
      └── Product

This makes it easier to understand relationships between operations and objects.

A visualizer does not discover new information independently; it organizes information already obtained from the schema.

8. GraphQL Suggestions: Discovering Schema Without Introspection

Disabling introspection does not necessarily prevent all schema discovery.

Some GraphQL implementations, particularly Apollo configurations, provide suggestions in error messages.

These suggestions can reveal valid field names when a query contains an invalid field.

For example, suppose the application contains:

type Query {
  productInformation(id: ID!): Product
}

A request referencing an incorrect field might generate an error similar to:

Cannot query field "productInfo".
Did you mean "productInformation"?

This response provides information about the underlying schema.

8.1 Why is This a Security Concern?

Even when introspection is disabled, detailed error messages may reveal:

• Valid field names.
• Operation names.
• Possible schema relationships.
• Incorrectly guessed field names.

By collecting enough suggestions, it may be possible to reconstruct parts of the schema.

8.2 Clairvoyance

Clairvoyance is a tool designed to recover GraphQL schema information through suggestions.

It can automate the process of sending queries and analyzing suggestion responses.

From a defensive perspective, this demonstrates why disabling introspection alone may not be sufficient.

8.3 Prevention

Developers should avoid exposing unnecessary schema details through client-facing error messages.

For Apollo Server v4 and above, the hideSchemaDetailsFromClientErrors configuration option can help disable schema suggestions.

Errors should remain useful for developers through appropriate internal logging without exposing unnecessary implementation details to external clients.

9. Bypassing GraphQL Introspection Defenses

Some applications attempt to disable introspection using simple request filters.

However, poorly designed filters may only inspect the textual representation of a query instead of understanding its GraphQL syntax.

9.1 Regex-Based Filtering

Imagine a developer wants to block introspection requests.

They create a regular expression that searches for:

__schema{

If the pattern is detected, the server rejects the request.

The problem is that GraphQL allows certain characters, including spaces, commas, and newlines, to be ignored between tokens.

For example:

query {
  __schema
  {
    queryType {
      name
    }
  }
}

This is still a valid GraphQL structure.

However, a filter looking only for the exact string:

__schema{

may fail to recognize it.

9.2 Text Matching vs GraphQL Parsing

There is an important difference between:

Text Matching

Checks whether a specific character sequence exists in a request.

GraphQL Parsing

Understands the structure and meaning of a GraphQL operation.

Security controls that rely only on text matching can be unreliable because multiple textual representations may describe the same GraphQL operation.

The correct approach is to apply security policies to the parsed GraphQL document rather than relying on fragile regular expressions.

9.3 Alternative Request Methods

Another common implementation mistake is blocking introspection only for one HTTP request format.

For example, a developer might filter POST requests but leave GET requests or URL-encoded POST requests available.

Depending on the server configuration, GraphQL queries may be accepted through:

• POST with JSON.
• GET with URL parameters.
• POST with application/x-www-form-urlencoded.

An authorized tester should verify that the same security policy applies across all supported request methods and content types.

For example:

POST /graphql HTTP/1.1
Content-Type: application/json

{
  "query": "{ __typename }"
}

A GET request might instead contain:

GET /graphql?query=%7B__typename%7D HTTP/1.1

The following URL-encoded characters are useful to recognize:

Encoded valueCharacter%7B{%7D}%0ANewline

The main lesson is that blocking one representation does not guarantee that every equivalent representation is blocked.

10. Bypassing Rate Limiting Using Aliases

GraphQL aliases provide a convenient way to request multiple instances of the same field within a single operation.

However, this feature can introduce a security weakness when rate limiting is implemented incorrectly.

10.1 Understanding the Problem

Consider a GraphQL API that checks whether a discount code is valid.

A traditional rate limiter might restrict the number of HTTP requests sent by a client.

For example:

Maximum: 10 HTTP requests per minute

However, one GraphQL HTTP request may contain multiple aliased fields.

For example:

query {
  product1: getProduct(id: 1) {
    name
  }

  product2: getProduct(id: 2) {
    name
  }
}

This means that multiple resolver executions can occur inside one HTTP request.

If the application only counts incoming HTTP requests, it may underestimate the actual amount of work being performed.

10.2 Root Cause

The problem is a mismatch between HTTP-level rate limiting and GraphQL-level operation execution.

A single request can contain:

• Multiple root fields.
• Multiple aliases.
• Nested selections.
• Expensive resolver operations.

Counting only HTTP requests does not necessarily reflect the real computational cost.

10.3 Potential Impact

Depending on the exposed functionality, insufficient limits can increase the risk of:

• Brute-force attempts.
• Excessive resource consumption.
• Automated enumeration.
• Denial-of-Service conditions.

10.4 Prevention

Developers should implement rate limiting that considers GraphQL operations rather than relying exclusively on HTTP request counts.

Useful controls include:

• Maximum number of aliases.
• Maximum number of root fields.
• Operation limits.
• Query complexity analysis.
• Execution time limits.
• Per-user and per-IP rate limits.

11. GraphQL Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery is a vulnerability that allows an attacker to induce a victim’s browser to send an unwanted request to an application where the victim is authenticated.

GraphQL endpoints can also be vulnerable to CSRF.

11.1 Understanding the Scenario

Imagine a user is logged in to an application.

The application uses a GraphQL mutation to change account information.

If the endpoint accepts requests that can be submitted cross-origin by a browser, and it does not implement appropriate CSRF protections, an attacker may be able to induce the victim’s browser to perform an unintended action.

The important point is that the browser may automatically include the victim’s authentication cookies.

11.2 How GraphQL CSRF Vulnerabilities Arise

A common combination of weaknesses is:

1. The GraphQL endpoint accepts requests using application/x-www-form-urlencoded.
2. The endpoint does not properly validate the request content type.
3. No effective CSRF token mechanism is implemented.
4. Authentication relies on cookies that the browser may automatically attach.

GET requests that perform state-changing operations are also dangerous.

The risk depends on the application’s authentication configuration, browser behavior, cookie settings, and cross-origin protections.

11.3 Why application/json Matters

A correctly enforced application/json requirement helps protect against traditional HTML form-based CSRF.

Ordinary HTML forms cannot directly submit arbitrary JSON bodies with an application/json content type.

However, developers should not rely on the content type alone as their entire security strategy.

A secure implementation should also consider:

• CSRF tokens.
• Origin validation.
• Appropriate SameSite cookie settings.
• Strict content-type validation.
• Correct CORS configuration.
• Preventing state-changing operations over GET.

CORS and CSRF are related to browser security but solve different problems. CORS alone should not be treated as a replacement for CSRF protection.

12. Burp Suite: GraphQL Security Testing Methodology

Burp Suite is particularly useful when testing GraphQL because it allows testers to inspect and modify HTTP requests and analyze server responses.

12.1 Identifying GraphQL Requests

Start by browsing the application through Burp’s browser.

Navigate to:

Proxy → HTTP history

Look for requests containing:

/graphql

or GraphQL operations inside their request bodies.

12.2 Sending Requests to Repeater

Once you identify a GraphQL request:

1. Right-click the request.
2. Select Send to Repeater.
3. Open the Repeater tab.
4. Examine the query and variables.
5. Modify the request within the authorized testing scope.
6. Compare the original and modified responses.

12.3 Understanding the GraphQL Request

Example:

POST /graphql HTTP/1.1
Host: example.local
Content-Type: application/json

{
  "query": "query getEmployee($id: ID!) { employee: getEmployee(id: $id) { id name } }",
  "variables": {
    "id": 1
  }
}

Important components:

ComponentMeaningPOST /graphqlGraphQL endpointqueryOperation typegetEmployeeOperation name$id: ID!Variable declarationid: $idArgumentemployee:Aliasid, nameRequested fieldsvariablesVariable values

Understanding these components makes it much easier to analyze complex requests.

12.4 Useful Burp Features

Proxy

Used to capture GraphQL requests and inspect application behavior.

Repeater

Used to modify requests and compare responses.

HTTP History

Used to identify GraphQL endpoints and application operations.

WebSockets History

Useful when investigating GraphQL subscriptions implemented over WebSockets.

GraphQL Support

Burp can identify GraphQL requests and provide a dedicated GraphQL view separating the query and variables.

InQL Extension

InQL is a Burp Suite extension designed to assist with GraphQL security testing.

Its features include:

• Schema analysis.
• Query and mutation generation.
• Introspection support.
• Sending generated requests to Repeater.
• Organizing discovered operations.

These features can help with reconnaissance, but manually validating authorization and application behavior remains essential.

13. Preventing GraphQL Attacks

Finding vulnerabilities is only one side of penetration testing. Understanding how to prevent them is equally important.

The following controls address the main weaknesses discussed in this article.

13.1 Disable Introspection Where Appropriate

For private APIs that do not require public schema discovery, consider disabling introspection in production.

However, public APIs may legitimately require introspection for documentation and developer tooling.

In those cases, carefully review the schema and ensure that it does not expose unintended information.

Disabling introspection is a defense-in-depth measure, not a replacement for authorization.

13.2 Disable Schema Suggestions

Error messages should not reveal unnecessary information about the API’s internal structure.

Disable or appropriately restrict suggestions and detailed schema errors in production.

For Apollo Server v4 and above, review:

hideSchemaDetailsFromClientErrors

Use the configuration appropriate to the installed server version.

13.3 Protect Sensitive Fields

Review the GraphQL schema to ensure that private user information is not unnecessarily exposed.

Examples include:

• Email addresses.
• Internal user identifiers.
• Private account information.
• Administrative metadata.
• Sensitive business data.

Remember that hiding a field in the frontend does not secure it.

Authorization must be enforced on the server.

13.4 Implement Strong Authorization

Every resolver that accesses sensitive resources should verify the authenticated user’s permissions.

For example, a resolver should not simply retrieve an object using an ID supplied by the client.

It should also verify that the current user is permitted to access that object.

Authorization checks should be consistent across:

• Queries.
• Mutations.
• Nested fields.
• Subscriptions.
• Different resolver paths accessing the same resource.

This is one of the most important protections against GraphQL IDOR vulnerabilities.

13.5 Implement Query Depth Limits

GraphQL supports nested fields, which can result in deeply nested operations.

For example:

query {
  user {
    orders {
      products {
        reviews {
          author {
            orders {
              products {
                id
              }
            }
          }
        }
      }
    }
  }
}

Deeply nested operations can create significant processing overhead.

Developers should configure maximum query depth limits to prevent excessively nested requests.

13.6 Implement Operation Limits

Query depth alone is not sufficient.

A relatively shallow query can still contain many fields or aliases.

Consider limiting:

• Total number of aliases.
• Number of root fields.
• Number of unique fields.
• Total operations per request.
• Maximum query size.

These restrictions help control the amount of work performed by a single GraphQL request.

13.7 Implement Query Complexity Analysis

Query complexity analysis estimates the computational cost of executing a GraphQL operation.

For example, a query retrieving a single user may be inexpensive.

A query retrieving thousands of users, each containing multiple nested collections, may be significantly more expensive.

The server can calculate an estimated cost before execution and reject operations that exceed an acceptable threshold.

This helps reduce resource exhaustion and abuse.

13.8 Enforce Proper Rate Limiting

Rate limiting should consider more than the number of HTTP requests.

A robust implementation should account for:

• Aliases.
• Root fields.
• Operation complexity.
• Authentication identity.
• Request frequency.
• Resource consumption.

The objective is to limit the actual workload generated by a client.

13.9 Prevent GraphQL CSRF

To reduce CSRF risks:

1. Accept queries through JSON-encoded POST requests where appropriate.
2. Validate that the actual request content matches the declared content type.
3. Implement secure CSRF tokens when cookie-based authentication requires them.
4. Validate request origins where appropriate.
5. Configure SameSite cookie attributes correctly.
6. Avoid allowing state-changing operations through GET requests.
7. Review CORS policies carefully.

No single control should be considered sufficient in every application.

14. Practical GraphQL Security Testing Checklist

During an authorized GraphQL penetration test, the following checklist can help organize the assessment.

Reconnaissance

• Identify possible GraphQL endpoints.
• Inspect HTTP History.
• Test for a valid GraphQL response using __typename.
• Identify supported HTTP methods.
• Examine request content types.
• Understand the application’s normal GraphQL operations.

Schema Discovery

• Check whether introspection is enabled.
• Identify available Queries.
• Identify available Mutations.
• Identify available Subscriptions.
• Review object Types and Fields.
• Examine arguments and input types.
• Review error messages and suggestions.
• Identify sensitive or unnecessary fields.

Access Control

• Review object-level authorization.
• Compare list and individual-object resolvers.
• Check whether private information is properly protected.
• Verify mutation authorization.
• Review nested field authorization.
• Verify subscription access controls.

Request and Resource Controls

• Review alias limits.
• Check query depth restrictions.
• Review operation limits.
• Check query complexity controls.
• Review rate limiting.
• Examine maximum request size.

CSRF

• Review accepted HTTP methods.
• Verify content-type validation.
• Review cookie configuration.
• Check CSRF token enforcement.
• Review CORS configuration.
• Ensure GET requests cannot perform state-changing operations.

15. Conclusion

GraphQL provides a flexible way to build and interact with APIs, but its flexibility also creates security challenges that developers and penetration testers must understand.

A single endpoint can expose numerous operations, fields, and relationships. Without proper authorization, resource restrictions, and input validation, these features can become entry points for security vulnerabilities.

The most important lesson is that GraphQL security is not simply about hiding the schema or disabling introspection.

Even when introspection is disabled, an application may still expose sensitive information through suggestions, error messages, improperly protected resolvers, or other implementation flaws.

As a penetration tester, the goal is to understand how the API works, identify where trust boundaries exist, and verify whether the server enforces the intended security rules.

As a developer, the goal is to ensure that every operation is properly authorized, every request is appropriately validated, and every resource-consuming operation is controlled.

A well-designed GraphQL API should not rely on obscurity. Its security should come from strong authorization, strict validation, and carefully designed resource controls.

References and Further Reading

1. PortSwigger Web Security Academy — GraphQL API Vulnerabilities
2. PortSwigger — What is GraphQL?
3. PortSwigger — Working with GraphQL in Burp Suite
4. PortSwigger — InQL GraphQL Scanner
5. GraphQL Official Documentation
6. Apollo Server Documentation

Disclaimer: All testing techniques discussed in this article should only be performed against systems you own or have explicit authorization to assess.

Introduction

Access control is one of the most important security mechanisms in modern web applications. It determines what authenticated users are allowed to access and which actions they can perform.

However, authentication does not automatically mean authorization. A user may successfully log in to an application while still attempting to access resources or functionality they are not permitted to use.

When an application fails to enforce these restrictions correctly, it can introduce Broken Access Control vulnerabilities.

Depending on the application and the permissions involved, these vulnerabilities may expose sensitive information, allow unauthorized modifications, or enable privilege escalation.

In this article, we will explore the fundamental concepts of access control, common vulnerability patterns, testing methodologies, and recommended security practices.

1. Authentication vs. Authorization

Before exploring access control vulnerabilities, it is important to understand three related concepts.

• Authentication: Verifies the identity of a user.
• Session management: Maintains the user’s authenticated state across requests.
• Authorization: Determines which resources and actions the user is permitted to access.

For example, logging in successfully proves that a user has authenticated. It does not mean that the user is authorized to access an administrator’s dashboard.

A secure application must verify permissions whenever a user attempts to access a protected resource or perform a sensitive operation.

2. Types of Access Control

Vertical Access Control

Vertical access control restricts functionality according to privilege levels or user roles.

For example, an administrator may be allowed to manage user accounts, while a regular user can only manage their own profile.

Vertical privilege escalation occurs when a user gains access to functionality intended for a more privileged role.

Horizontal Access Control

Horizontal access control restricts access to resources belonging to individual users.

For example, a customer should be able to view their own orders but should not be able to access another customer’s private order history.

Horizontal privilege escalation occurs when a user accesses another user’s resources without obtaining a higher privilege level.

Context-Dependent Access Control

Some applications restrict actions according to the current state of a workflow.

For example, an application may allow a customer to modify an order before confirmation but prevent changes after the order has been finalized.

A vulnerability occurs when an application fails to enforce these restrictions consistently.

3. Common Access Control Vulnerabilities

3.1 Unprotected Administrative Functionality

Administrative pages are often designed to be accessible only to privileged users.

Consider an endpoint such as:

https://example.com/admin

If the application does not verify the current user’s permissions, an ordinary user might access administrative functionality simply by requesting the endpoint directly.

Removing an administrative link from the user interface does not prevent direct access to the underlying resource.

The server must independently enforce the appropriate permissions.

3.2 Security Through Obscurity

Some applications attempt to protect administrative functionality by using difficult-to-guess URLs.

For example:

https://example.com/administrator-panel-x7k29

Although an obscure URL may make discovery more difficult, it does not provide reliable authorization.

If the URL becomes known, the application must still prevent unauthorized users from accessing the resource.

Key takeaway: Hiding functionality is not the same as securing it.

3.3 Parameter-Based Access Control

Applications sometimes use request parameters or cookies to represent user roles and permissions.

For example:

GET /account?role=user

A poorly designed application may trust client-controlled information when deciding whether to grant access to privileged functionality.

If the server relies on such values without verifying the user’s actual permissions, the authorization mechanism may be bypassed.

Similar weaknesses can involve cookies, hidden form fields, and JSON request properties.

The fundamental problem is trusting information supplied by the client instead of enforcing authorization using trusted server-side data.

3.4 Insecure Direct Object References (IDOR)

An Insecure Direct Object Reference occurs when an application uses a user-controlled identifier to retrieve an object without correctly checking whether the current user is authorized to access it.

Consider this request:

GET /account?id=1001

The application uses the identifier to select an account.

If it checks only whether the account exists, rather than whether the current user is allowed to access it, private information may be exposed.

IDOR vulnerabilities can affect user profiles, invoices, documents, private messages, orders, and API resources.

The identifier does not have to be numeric. UUIDs and other identifiers can also be involved.

The essential issue is missing authorization, not the predictability of the identifier.

3.5 Horizontal and Vertical Privilege Escalation

These two vulnerability classes describe different authorization failures.

Horizontal escalation occurs when a user accesses resources belonging to another user at the same privilege level.

Vertical escalation occurs when a user obtains access to functionality associated with a higher privilege level.

In some cases, a horizontal access control flaw can expose information that contributes to a more serious privilege escalation.

3.6 URL-Based Access Control Bypass

Web applications may use reverse proxies, web servers, and application frameworks to process requests.

If these components interpret a URL differently, access restrictions may not be applied consistently.

Some environments recognize headers such as X-Original-URL or X-Rewrite-URL. When routing and authorization logic disagree about the effective request path, protected resources may become accessible.

The underlying problem is inconsistent request interpretation between application components.

3.7 HTTP Method-Based Access Control Bypass

Applications support different HTTP methods, including GET, POST, PUT, PATCH, and DELETE.

A poorly implemented authorization mechanism may restrict an operation when one method is used but fail to enforce the same restriction for another accepted method.

Authorization should apply to the underlying action, regardless of the HTTP method used to invoke it.

3.8 Referer-Based Access Control

The HTTP Referer header can indicate the page from which a request originated.

However, this header can be manipulated by a client and should not be treated as proof of authorization.

If an application grants access to a sensitive operation based only on the presence of a particular Referer value, the restriction may be bypassed.

Authorization decisions must rely on trusted identity and permission checks.

3.9 Multi-Step Workflow Vulnerabilities

Some sensitive operations require several steps.

For example:

1. Opening a form.
2. Submitting a change.
3. Confirming the operation.

An application may verify permissions during the first step but fail to repeat the necessary checks during a later step.

If the final operation can be reached independently, the workflow may allow unauthorized actions.

Every sensitive server-side operation must enforce its own authorization requirements.

4. Testing Access Control with Burp Suite

Burp Suite is useful for examining HTTP requests and evaluating how an application enforces permissions.

Step 1: Map the Application

Identify important pages, API endpoints, user roles, and sensitive operations.

Determine which actions should be available to regular users and which should be restricted to administrators.

Step 2: Inspect HTTP Requests

Use Burp Suite Proxy and HTTP history to examine requests and responses.

Pay attention to:

• URL paths and query parameters.
• Cookies and authorization headers.
• HTTP methods.
• JSON request bodies.
• Identifiers associated with individual resources.

These components help reveal how the application identifies resources and processes actions.

Step 3: Compare User Permissions

Where authorized test accounts are available, compare the behavior of users with different privilege levels.

Check whether the server correctly enforces the expected restrictions rather than relying on the user interface.

Step 4: Examine Resource Ownership

Review requests that retrieve or modify user-specific resources.

Determine whether the server verifies that the current user owns the requested object or has another explicit permission to access it.

Step 5: Review Sensitive Workflows

Examine multi-step operations and verify that authorization checks are consistently enforced throughout the workflow.

Also consider whether supported HTTP methods and alternate application routes apply the same security restrictions.

Step 6: Confirm the Vulnerability

A suspected issue should be validated using a controlled test account and an authorized, harmless test.

Record the affected endpoint, expected behavior, actual behavior, and demonstrated impact.

A successful HTTP response alone does not prove a vulnerability. The evidence must demonstrate that an unauthorized resource or operation was actually accessible.

5. Security Impact

The impact of a broken access control vulnerability depends on the permissions involved and the sensitivity of the affected resources.

Potential consequences include:

• Unauthorized disclosure of private information.
• Access to another user’s account records.
• Unauthorized modification or deletion of data.
• Exposure of administrative functionality.
• Privilege escalation.
• Compromise of confidentiality and data integrity.

Not every access control issue has the same severity. Risk should be evaluated according to the demonstrated impact and realistic exploitability.

6. Prevention and Mitigation

Enforce Authorization on the Server

Every sensitive request must be checked against the authenticated user’s permissions before the requested operation is performed.

Apply Deny-by-Default

Access should be denied unless the application explicitly determines that the request is authorized.

Verify Resource Ownership

When users request individual records, verify that they own those records or have an appropriate permission to access them.

Avoid Trusting Client-Controlled Roles

Do not treat query parameters, hidden fields, or editable cookies as authoritative proof of a user’s privileges.

Centralize Authorization Logic

Use consistent authorization mechanisms across application endpoints to reduce the risk of individual routes implementing weaker checks.

Validate Every Sensitive Operation

Enforce authorization for API endpoints, administrative actions, and every relevant stage of multi-step workflows.

Test Different User Roles

Perform regular security testing with accounts representing different privilege levels. Verify both allowed and denied operations.

Monitor Security-Relevant Events

Log appropriate authorization failures and sensitive administrative actions without unnecessarily recording secrets or session tokens.

7. Key Lessons

Working through access control concepts highlights several important principles:

1. Authentication and authorization solve different security problems.
2. Hidden URLs do not replace proper permission checks.
3. IDOR vulnerabilities arise when access to an object is not correctly authorized.
4. Vertical and horizontal privilege escalation affect different permission boundaries.
5. Client-controlled values and headers should not determine authorization by themselves.
6. Every sensitive endpoint must enforce the intended permissions.
7. Security testing must verify actual unauthorized access, not simply successful HTTP responses.

Conclusion

Broken access control is a significant web application security risk because it allows users to perform actions or access resources beyond their intended permissions.

Understanding vertical and horizontal privilege escalation, IDOR, URL-based restrictions, and workflow weaknesses provides a strong foundation for identifying these vulnerabilities.

Using Burp Suite to inspect requests, compare user roles, and validate authorization decisions can help security testers assess whether an application enforces its intended security boundaries.

Ultimately, effective access control depends on consistent server-side authorization, explicit permission checks, and systematic testing.

References

• PortSwigger Web Security Academy — Access Control
• OWASP Top 10 — Broken Access Control
• PortSwigger Web Security Knowledge Base — Broken Access Control

1. Introduction

SQL Injection (SQLi) is a web application vulnerability that occurs when an application incorporates user-controlled input into SQL queries without handling it safely.

SQL queries allow applications to interact with databases. When input is processed incorrectly, it may change the logic of a query and cause the application to behave in unintended ways.

Depending on the vulnerability and database permissions, SQL injection may allow unauthorized data access, authentication bypass, or modification of database records.

This writeup covers the major concepts in the SQL Injection learning path from PortSwigger Web Security Academy, including detection, UNION attacks, blind SQL injection, database identification, and prevention.

Learning resource: PortSwigger SQL Injection Learning Path

2. Understanding SQL Injection

Consider a simple SQL query used to retrieve products from a database:

SELECT * FROM products
WHERE category = 'Books';

The application returns products belonging to the Books category.

A vulnerability may occur when an application constructs SQL queries by concatenating user input directly into a query string.

The core problem is that the database may interpret part of the input as SQL syntax instead of treating the entire input as data.

The important distinction is:

• Safe handling: User input is supplied as a parameter.
• Unsafe handling: User input changes the structure or logic of the SQL statement.

SQL injection is therefore primarily a problem of how applications construct and execute database queries.

3. Detecting SQL Injection Vulnerabilities

The first step in testing for SQL injection is identifying inputs that may influence database queries.

Potential entry points include:

• URL query parameters
• Search fields
• Login forms
• Product filters
• Cookies
• HTTP headers
• JSON and XML request bodies

Testing for unusual behavior

A tester can compare a normal request with carefully controlled test inputs.

For example, a single quote character may reveal an error if the application handles SQL strings incorrectly.

However, an error alone does not prove that SQL injection exists.

Look for repeatable differences such as:

• Database-related error messages
• Changes in returned content
• Unexpected HTTP status codes
• Different responses to logically different conditions
• Consistent response delays

A useful methodology is to record a baseline request, change one input at a time, and compare the responses.

SQL injection in different parts of a query

SQL injection is not limited to string values in a WHERE clause. Depending on how an application constructs its queries, user input may affect other parts of a statement, including sorting expressions or other query components.

The appropriate testing method depends on the context in which the input is used.

4. Retrieving Hidden Data

Applications sometimes use SQL queries to filter records according to user-selected categories or other parameters.

For example:

SELECT * FROM products
WHERE category = 'Books'
AND visible = TRUE;

The application may intend to show only products that belong to a particular category and are marked as visible.

If the query is vulnerable, its logic may be altered so that records normally hidden from users are returned.

The security impact depends on the query, the application, and the database permissions.

Key lesson: A filter in the user interface is not a reliable security boundary unless access to the underlying data is also properly controlled.

5. Subverting Application Logic

SQL injection can also affect application logic.

For example, an application might check credentials with a query conceptually similar to:

SELECT * FROM users
WHERE username = ?
AND password = ?;

If the application constructs this query unsafely, an attacker may be able to interfere with the conditions used for authentication.

This can potentially lead to authentication bypass.

The key issue is not the appearance of the login form. It is whether the server safely constructs and evaluates the database query.

Applications should use parameterized queries and established authentication mechanisms instead of building SQL statements from untrusted strings.

6. SQL Injection UNION Attacks

The SQL UNION operator combines the results of two or more SELECT queries.

For example:

SELECT name, category FROM products
UNION
SELECT name, category FROM archived_products;

This combines rows from both queries into a single result set.

In a vulnerable application, a UNION-based SQL injection may allow the results of another query to appear in the application’s response.

Requirements for UNION

The queries combined with UNION generally need to satisfy two important requirements:

1. Both queries must return the same number of columns.
2. Corresponding columns must have compatible data types.

These requirements explain why a UNION attack cannot always be constructed immediately.

Determining the number of columns

The number of columns returned by the original query is important because a compatible UNION query must return the same number.

In an authorized lab, this can be investigated by observing how controlled test queries affect the response.

Finding a column with a suitable data type

Even when the column count is known, the data types must be compatible.

For example, a column containing text may be suitable for displaying a username, whereas a numeric column may not accept an arbitrary text value.

The general learning process is to establish the column count, understand the relevant data types, and observe how the application presents query results.

7. Retrieving Data from Other Tables

A database often contains multiple tables that serve different purposes.

For example:

TablePurposeproductsProduct informationusersUser accountsordersCustomer orderscategoriesProduct categories

A vulnerable query may expose data from tables that the application did not intend to display through that page.

The potential impact can include unauthorized access to personal or business information.

This is one reason database permissions should be restricted to the minimum required for each application component.

8. Retrieving Multiple Values from One Column

Sometimes the original query returns only one suitable column.

In certain database systems, string concatenation can combine several values into a single string.

For example, conceptually:

username + separator + email

The separator helps distinguish one value from another when they appear together.

The exact concatenation syntax varies between database systems. Therefore, identifying the database type can be important when studying SQL injection behavior.

9. Examining the Database

Understanding the database structure can help explain how an application stores and retrieves information.

Two important questions are:

• Which database management system is being used?
• Which tables and columns exist in the database?

Identifying the database type

Different database systems have their own syntax and built-in functions.

Common examples include:

• MySQL
• Microsoft SQL Server
• PostgreSQL
• Oracle Database

Differences in syntax can help identify the database system when testing a controlled lab.

Database metadata

Database systems often provide metadata that describes the database structure.

Depending on the system and permissions, this metadata may reveal information about tables, columns, and other database objects.

Understanding database metadata is useful for both database administration and security testing.

Important: Database-specific syntax is not universal. A query that works on one database may fail on another.

10. Blind SQL Injection

Blind SQL injection occurs when an application is vulnerable to SQL injection but does not directly return the results of the relevant query or detailed database errors.

The application may appear to respond normally even when its database query has been affected.

In this situation, testers must rely on indirect evidence.

Common forms include:

• Boolean-based testing
• Conditional error behavior
• Time-based behavior
• Out-of-band interactions

Boolean-based behavior

A boolean condition evaluates to either true or false.

A tester can compare responses to controlled conditions and determine whether the application’s behavior consistently reflects the result.

For example, the application might return different content depending on whether a condition evaluates to true or false.

Consistent differences can provide evidence of a SQL injection vulnerability.

Conditional errors

Some applications handle database errors differently depending on what happens during query execution.

If a controlled condition consistently causes a particular error behavior, that difference may reveal information about the query.

However, errors should be interpreted carefully because unrelated application failures can produce similar symptoms.

Time-based behavior

Some database expressions can cause a query to pause.

If an application is vulnerable, a controlled test may cause a repeatable delay even when the response contains no useful database output.

A single slow request is not sufficient evidence. Network latency, server load, and other factors can also affect response times.

Out-of-band testing

Out-of-band application security testing, or OAST, uses a separate communication channel to detect certain interactions.

This may help identify vulnerabilities when the application’s normal HTTP response does not reveal what happened in the database.

The observed interaction must be correlated with the controlled test before drawing conclusions.

11. SQL Injection in Different Contexts

SQL injection can occur in inputs other than ordinary URL parameters.

For example, an application might accept structured data in JSON or XML and then use that data to construct a SQL query.

The request format does not automatically make the application safe.

Security testers should understand how the server parses the request and how the resulting values are used in database queries.

Encoding and filtering

Applications may decode or transform incoming data before processing it.

For this reason, security testing must consider how input is handled across the entire processing chain.

Simple keyword filtering is not a dependable defense against SQL injection. Correct query construction is much more important than attempting to block individual SQL keywords.

12. Second-Order SQL Injection

Second-order SQL injection occurs when input is stored first and later used unsafely in a SQL query.

The initial action may appear harmless because the input is only saved.

The vulnerability becomes relevant when another part of the application retrieves that stored value and incorporates it into a new query without proper parameterization.

Conceptually:

User input
    ↓
Stored in the database
    ↓
Retrieved later
    ↓
Used unsafely in a new SQL query
    ↓
Unexpected query behavior

This illustrates why security testing should examine how data moves through an application, not only what happens when a form is submitted.

Input that was previously stored should still be treated as untrusted data.

13. How Burp Suite Helps with SQL Injection Testing

Burp Suite provides useful tools for inspecting and comparing HTTP traffic during authorized security assessments.

Proxy

Burp Proxy allows testers to inspect requests and responses between the browser and the application.

It helps identify parameters, cookies, headers, and request-body fields.

HTTP history

HTTP history records requests and responses, making it easier to identify which input was submitted and what the application returned.

Repeater

Repeater allows a captured request to be sent again after controlled modifications.

This is useful for comparing a baseline request with a test request.

A careful workflow is:

1. Capture a normal request.
2. Send it to Repeater.
3. Change one input.
4. Send the request again.
5. Compare the response status, body, and timing.
6. Repeat to confirm that the behavior is consistent.

Changing one variable at a time makes the results easier to interpret.

14. Preventing SQL Injection

The most important defense against SQL injection is to ensure that user input cannot change the intended SQL query structure.

Parameterized queries

Parameterized queries separate SQL code from user-supplied values.

For example, in Java:

String query =
    "SELECT * FROM products WHERE category = ?";

PreparedStatement statement =
    connection.prepareStatement(query);

statement.setString(1, category);

The category is passed as a parameter instead of being concatenated directly into the query string.

This helps the database treat the value as data rather than executable SQL syntax.

Additional defenses

• Use parameterized queries or prepared statements.
• Avoid concatenating untrusted input into SQL statements.
• Use allowlists for dynamic identifiers such as table names or sort fields.
• Apply least-privilege permissions to database accounts.
• Avoid displaying detailed database errors to end users.
• Test applications regularly for security vulnerabilities.
• Use secure frameworks and database libraries.
• Review stored values when they are later used in queries.

Input validation can provide additional protection, but it should not replace parameterized queries.

15. Common Mistakes During SQL Injection Testing

Assuming every error proves a vulnerability

An error may result from unrelated application logic. Additional evidence is needed.

Ignoring the original response

A baseline response provides a reference for understanding whether the test changed the application’s behavior.

Testing only URL parameters

Cookies, headers, JSON fields, and other inputs may also influence database queries.

Relying on a single timing result

One delayed response may be caused by normal performance variations. Repeatable comparisons are more reliable.

Forgetting database differences

Different database systems support different functions and syntax.

Confusing detection with confirmation

A suspicious response is a clue. A well-supported finding requires repeatable evidence that connects the input to the unexpected query behavior.

16. SQL Injection Testing Workflow

The following workflow summarizes the main concepts:

Understand the application
          ↓
Identify database-related inputs
          ↓
Record a baseline request
          ↓
Test input handling
          ↓
Compare application responses
          ↓
Investigate relevant SQL behavior
          ↓
Confirm the finding
          ↓
Document impact and evidence
          ↓
Recommend remediation

Testing should remain within the scope of an authorized lab or security assessment.

17. Key Takeaways

The major lessons from the SQL Injection learning path are:

• SQL injection happens when user input can interfere with SQL query construction.
• A vulnerability may affect data retrieval, authentication, or other application behavior.
• UNION attacks depend on compatible column counts and data types.
• Database metadata can describe tables and columns.
• Blind SQL injection relies on indirect observations rather than directly returned query results.
• Boolean, conditional-error, time-based, and out-of-band techniques provide different forms of evidence.
• Second-order SQL injection can occur when stored input is used unsafely later.
• Burp Suite helps inspect requests and compare responses.
• Parameterized queries are a primary defense against SQL injection.
• Reliable testing requires controlled experiments, repeatable results, and careful interpretation.

Conclusion

The SQL Injection learning path provides a foundation for understanding how web applications interact with databases and how unsafe query construction can introduce serious vulnerabilities.

The most important skill is learning to reason about application behavior: identify where input enters the system, understand how the application processes it, compare controlled responses, and distinguish reliable evidence from false positives.

For anyone learning web penetration testing, SQL injection is an important topic because it combines HTTP analysis, SQL fundamentals, application logic, and secure coding principles.

Introduction

After learning the fundamentals of the Metasploit Framework, the next step is understanding how Metasploit can be used during a penetration testing workflow.

In this TryHackMe room, I explored how Metasploit can be used for:

• Network and service scanning
• Managing information with the Metasploit database
• Vulnerability scanning
• Exploiting vulnerable services
• Generating payloads with msfvenom
• Establishing Meterpreter sessions

All practical activities in this writeup are performed inside the authorized TryHackMe lab environment.

1. Starting Metasploit

The main interface of Metasploit is msfconsole.

msfconsole

After launching it, the prompt becomes:

msf6 >

From here, we can search for modules, perform scans, configure exploits, and manage sessions.

2. Scanning with Metasploit

Metasploit includes several auxiliary modules that can be used for reconnaissance and service enumeration.

The general workflow is:

Search for a scanner
        ↓
Select the module
        ↓
Configure the target
        ↓
Run the scanner
        ↓
Analyse the results

For example:

search scanner

This searches for available scanning modules.

After finding an appropriate module:

use <scanner_module>

Then we can inspect its options:

show options

And configure the target:

set RHOSTS <LAB_TARGET_IP>

Finally:

run

The purpose of this stage is to identify services and information that may later be useful during vulnerability assessment.

3. The Metasploit Database

Metasploit includes a database feature that helps organize information collected during a penetration test.

This becomes especially useful when working with multiple hosts and services.

The database can store information such as:

• Hosts
• Services
• Credentials
• Vulnerabilities
• Scan results

Before using database features, the database status can be checked with:

db_status

A properly configured database allows Metasploit to keep information from different activities in one place.

4. Working with Hosts

After scanning a target, information can be stored in the Metasploit database.

To display discovered hosts:

hosts

This can provide information about systems that have been identified during the assessment.

For example, a host entry may contain information such as:

Address
Hostname
Operating System
Purpose

This is useful when dealing with larger lab environments.

5. Working with Services

The services command can be used to display discovered services.

services

The output can contain information such as:

• IP address
• Port
• Protocol
• Service
• Version

For example:

PORT
80/tcp
22/tcp
445/tcp

Knowing which services are available helps determine which vulnerabilities or exploits may be relevant.

6. Vulnerability Scanning

Metasploit can also be used to perform vulnerability scanning.

The general idea is:

Discover services
       ↓
Identify versions
       ↓
Search for vulnerabilities
       ↓
Select an appropriate module
       ↓
Validate the target

For example, after discovering a service, we can search Metasploit for related modules:

search <service>

The search results may contain auxiliary scanners, exploits, or other modules.

7. Finding an Exploit

Once a vulnerable service has been identified, Metasploit can be searched for an appropriate exploit.

The basic syntax is:

search <keyword>

For example:

search smb

The results can contain different module types.

Before using an exploit, it is important to understand:

• Which vulnerability it targets
• Which operating system it supports
• Which service/version it affects
• Which options are required
• Which payloads are compatible

8. Selecting an Exploit

After identifying an appropriate module:

use <exploit_module>

Then inspect the module:

info

And check its configuration:

show options

The required parameters should be configured before execution.

For example:

set RHOSTS <LAB_TARGET_IP>

Depending on the exploit, additional parameters may be required.

9. Checking the Exploit

Some Metasploit modules support:

check

This attempts to determine whether the target is vulnerable without performing the full exploitation process.

This can be useful because it provides an additional validation step before running an exploit.

The workflow becomes:

Select exploit
      ↓
Configure options
      ↓
check
      ↓
exploit

10. Exploitation

Once the target and required parameters are configured, an exploit can be launched with:

run

or:

exploit

The exact result depends on the exploit and payload being used.

If successful, Metasploit may establish a session with the target.

11. Understanding Payloads

An exploit and a payload are different concepts.

Exploit

The exploit takes advantage of a vulnerability.

Payload

The payload defines what happens after successful exploitation.

Conceptually:

Vulnerability
      ↓
   Exploit
      ↓
   Payload
      ↓
   Session

This distinction is important when working with Metasploit.

12. Meterpreter

One of the most important payload/session types in Metasploit is Meterpreter.

Meterpreter provides an interactive environment for authorized post-exploitation activities.

A successful Meterpreter session may look similar to:

meterpreter >

The session can then be managed through Metasploit.

To see available sessions:

sessions

To interact with a particular session:

sessions -i <SESSION_ID>

13. Backgrounding a Session

A session does not necessarily need to be closed when returning to the Metasploit console.

You can background the current session with:

background

The session remains available.

You can later list sessions:

sessions

and interact with one again:

sessions -i <SESSION_ID>

This is useful when working with multiple sessions.

14. Msfvenom

Another important component covered in this room is msfvenom.

msfvenom is a Metasploit tool used to generate payloads.

Its general structure includes:

msfvenom -p <PAYLOAD> <OPTIONS>

The exact payload and configuration depend on the authorized lab scenario.

A payload may require parameters such as:

LHOST
LPORT

These determine where a connection should be directed in the lab environment.

15. Payload Generation Workflow

The general workflow for msfvenom is:

Choose a payload
       ↓
Configure required parameters
       ↓
Choose an output format
       ↓
Generate the payload
       ↓
Use it in the authorized lab
       ↓
Establish a session

This demonstrates how Metasploit can be used not only to exploit existing vulnerabilities but also to generate payloads for controlled testing environments.

16. Meterpreter Session Workflow

A simplified workflow looks like this:

Generate payload
       ↓
Prepare the lab listener
       ↓
Execute payload in the lab
       ↓
Receive connection
       ↓
Meterpreter session

Once the session is established, Metasploit can manage it through the session interface.

17. Why the Database Is Useful

The Metasploit database becomes especially valuable when a penetration test involves multiple systems.

Instead of keeping information separately, Metasploit can organize discovered information.

For example:

Host
 ├── Services
 ├── Ports
 ├── Vulnerabilities
 └── Other collected information

This makes it easier to understand the overall attack surface of a lab environment.

18. Metasploit Exploitation Workflow

The complete workflow covered in this room can be summarized as:

1. Scan the target
        ↓
2. Identify services
        ↓
3. Store information in the database
        ↓
4. Identify potential vulnerabilities
        ↓
5. Search for an appropriate module
        ↓
6. Configure the exploit
        ↓
7. Validate when possible
        ↓
8. Execute the exploit
        ↓
9. Obtain and manage a session

This workflow is much more important than memorizing individual commands.

19. Important Commands

CommandPurposemsfconsoleStart Metasploitsearch <term>Search for modulesuse <module>Select a moduleinfoDisplay module informationshow optionsDisplay module optionsset <option> <value>Configure an optionunset <option>Remove an optioncheckCheck vulnerability when supportedrunExecute a moduleexploitLaunch an exploitdb_statusCheck database connectionhostsDisplay database hostsservicesDisplay discovered servicessessionsList active sessionssessions -i <ID>Interact with a sessionbackgroundBackground the current session

20. Key Takeaways

The main concepts I learned from this room are:

• Metasploit can perform network and service scanning.
• The Metasploit database helps organize information from an assessment.
• Services discovered during scanning can be used to identify potential vulnerabilities.
• Metasploit provides exploit modules for many known vulnerabilities.
• Exploits and payloads serve different purposes.
• msfvenom can generate payloads.
• Meterpreter provides an interactive session after successful exploitation.
• Sessions can be managed directly from Metasploit.
• A structured workflow is essential when using an exploitation framework.

Conclusion

The Metasploit: Exploitation room builds on the fundamentals learned in the previous Metasploit room and introduces a more complete penetration testing workflow.

The most important concept is understanding how the different components connect:

Scanning
   ↓
Enumeration
   ↓
Vulnerability Identification
   ↓
Exploit Selection
   ↓
Payload
   ↓
Session

Learning this workflow provides a foundation for more advanced penetration testing concepts and helps explain how exploitation frameworks are used during authorized security assessments.

All exploitation techniques discussed here should only be practiced against systems where you have explicit permission, such as TryHackMe labs and other authorized environments.

Introduction

Metasploit is one of the most widely used penetration testing frameworks. It provides a structured environment for security testing, including vulnerability research, scanning, exploitation, and post-exploitation.

In this TryHackMe room, I learned the fundamentals of the Metasploit Framework, including how to navigate msfconsole, understand different module types, search for modules, configure parameters, use payloads, and manage sessions.

All practical exploitation in this writeup is performed in the authorized TryHackMe lab environment.

1. What is Metasploit?

Metasploit is an open-source penetration testing framework designed to help security professionals test vulnerabilities in controlled environments.

The main version covered in this room is Metasploit Framework, which is primarily operated through the command-line interface.

The main components include:

• msfconsole — the main Metasploit command-line interface
• Modules — components designed for specific security-testing tasks
• Payloads — code executed after successful exploitation
• Auxiliary modules — scanners and other supporting tools
• Post modules — modules used during post-exploitation
• msfvenom — a standalone tool for generating payloads

Metasploit can support several stages of a penetration test, from information gathering to post-exploitation.

2. Vulnerability, Exploit and Payload

Before working with Metasploit, it is important to understand three fundamental concepts.

Vulnerability

A vulnerability is a weakness or flaw in software, configuration, design, or logic.

For example, outdated software may contain a known vulnerability.

Exploit

An exploit is code or a technique that takes advantage of a vulnerability.

In simple terms:

Vulnerability
      ↓
   Exploit
      ↓
Target behavior / access

Payload

A payload is the code delivered or executed after an exploit successfully takes advantage of a vulnerability.

A simple way to remember the difference is:

Vulnerability = The weakness

Exploit = The method used to take advantage of the weakness

Payload = What is executed after exploitation

Understanding these three concepts is essential when working with Metasploit.

3. Starting Metasploit

Metasploit can be launched using:

msfconsole

After starting it, the prompt changes to something similar to:

msf6 >

This is the main Metasploit console.

From here, we can search for modules, select modules, configure parameters, and execute them in the authorized lab environment.

4. Metasploit Modules

Metasploit is modular. Each module is designed for a particular task.

Some important module categories are:

Auxiliary

Auxiliary modules provide supporting functionality such as:

• Scanning
• Enumeration
• Crawling
• Fuzzing

Example:

auxiliary/scanner/

Exploit

Exploit modules contain code designed to take advantage of specific vulnerabilities.

Example:

exploit/windows/smb/

Payload

Payloads define what happens after successful exploitation.

Examples include shell-based payloads and other payload types.

Post

Post modules are used after gaining access to a target.

They can help with tasks such as information gathering and further assessment.

Encoders

Encoders can transform payload data into different representations. They are one of the module categories available in Metasploit.

NOPs

NOP modules provide no-operation instructions and are historically useful in certain exploitation techniques.

5. Searching for Modules

One of the most useful commands in Metasploit is:

search

For example, to search for modules related to Apache:

search apache

Metasploit will return matching modules.

You can then inspect a specific module before using it.

6. Selecting a Module

After finding a relevant module, the use command selects it.

Example:

use auxiliary/scanner/ssh/ssh_login

The prompt changes to show the selected context:

msf6 auxiliary(scanner/ssh/ssh_login) >

This tells us which module is currently selected.

7. Viewing Module Information

Before configuring a module, it is useful to inspect it.

The command:

info

can display information about the selected module.

You can also use:

show options

This displays the parameters that can be configured.

8. Important Metasploit Parameters

Metasploit modules often require different parameters.

Some common ones are:

RHOSTS

RHOSTS means Remote Hosts.

It identifies the target system or systems.

set RHOSTS <LAB_TARGET_IP>

RPORT

RPORT means Remote Port.

It specifies the port of the service being tested.

set RPORT <LAB_PORT>

LHOST

LHOST means Local Host.

It represents the IP address of the machine running Metasploit when a connection needs to return to the testing machine.

set LHOST <YOUR_LAB_IP>

LPORT

LPORT means Local Port.

It specifies the local port used for the connection.

set LPORT <LAB_PORT>

PAYLOAD

The PAYLOAD parameter specifies the payload used by the exploit.

9. Setting Parameters

Metasploit uses the following syntax:

set PARAMETER VALUE

For example:

set RHOSTS <LAB_TARGET_IP>

After configuring the module, always check the settings with:

show options

This helps verify that the required parameters have been configured correctly.

10. Clearing a Parameter

If you want to remove a previously configured payload, you can use:

unset PAYLOAD

The unset command removes a configured value.

You can also clear all configured parameters with:

unset all

11. Checking a Target

Some Metasploit modules support:

check

The check command can determine whether the target appears vulnerable without actually launching the exploit.

This can be useful when validating a vulnerability before exploitation.

12. Launching a Module

Once the required parameters have been configured, the module can be executed with:

run

For exploit modules, another commonly used command is:

exploit

The room demonstrates the exploitation workflow using a vulnerable lab target.

The general process is:

Find a module
      ↓
Select the module
      ↓
Configure parameters
      ↓
Check options
      ↓
Check vulnerability (if supported)
      ↓
Run the module

13. Sessions

When an exploit successfully establishes communication with a target, Metasploit can create a session.

A session represents an active communication channel between Metasploit and the target.

You can view active sessions using:

sessions

A session can be moved to the background with:

background

or:

CTRL + Z

This returns you to the Metasploit console while keeping the session available.

14. Understanding Metasploit Prompts

It is important to recognize the different prompts.

Normal Linux terminal

root@kali:~#

This is your normal operating-system shell.

Metasploit console

msf6 >

This means you are at the main Metasploit console.

Module context

msf6 exploit(...) >

This means a specific module has been selected.

Session shell

Depending on the payload and target, you may receive a shell or another type of session.

Understanding the current prompt helps prevent mistakes when entering commands.

15. Linux Commands Inside Metasploit

Metasploit can also execute some operating-system commands.

For example:

ls

Metasploit can execute the command and display the result.

This is useful for interacting with the underlying system when appropriate.

16. Single and Staged Payloads

Metasploit supports different payload structures.

A single/inline payload contains the required functionality together.

A staged payload is divided into components:

Stager
   ↓
Stage

The stager establishes the communication channel and the stage provides the remaining functionality.

The room shows how payload names can indicate whether a payload is staged or single.

For example:

generic/shell_reverse_tcp

and:

windows/x64/shell/reverse_tcp

have different naming structures.

17. The Exploitation Workflow

The room summarizes the Metasploit workflow into three important stages:

1. Find the appropriate exploit
          ↓
2. Configure the exploit
          ↓
3. Execute the exploit

The important part is not simply memorizing commands.

You need to understand:

• What vulnerability you are testing
• Why the module is relevant
• Which parameters are required
• What payload is being used
• What type of session is expected

18. Key Commands Cheat Sheet

CommandPurposemsfconsoleStart Metasploitsearch <term>Search for modulesuse <module>Select a moduleinfoDisplay module informationshow optionsDisplay module parametersset <option> <value>Configure a parameterunset <option>Remove a parameterunset allClear configured parameterscheckCheck vulnerability if supportedrunExecute a moduleexploitLaunch an exploitsessionsList active sessionsbackgroundBackground the current sessionhelpDisplay available commands

19. What I Learned

After completing this room, I understood the basic architecture and workflow of the Metasploit Framework.

The most important concepts I learned were:

• What Metasploit is
• How msfconsole works
• The difference between vulnerabilities, exploits, and payloads
• The different Metasploit module categories
• How to search for modules
• How to select and inspect modules
• How to configure parameters
• The purpose of RHOSTS, RPORT, LHOST, and LPORT
• How to check a target when a module supports check
• How sessions work
• How to background and manage sessions
• The difference between staged and single payloads

Conclusion

Metasploit is more than a collection of exploits. It provides a structured framework for conducting controlled security testing.

The most important lesson from this room is understanding the workflow:

Identify a vulnerability
        ↓
Find a suitable module
        ↓
Configure the module
        ↓
Validate the configuration
        ↓
Execute in an authorized lab
        ↓
Manage the resulting session

Learning these fundamentals provides a strong foundation for more advanced Metasploit topics, including vulnerability scanning, database management, Meterpreter, payload generation, and post-exploitation.

For me, this room was an important step toward understanding how exploitation frameworks fit into a penetration testing methodology.

Introduction

Databases are one of the most important components of modern web applications.

Websites and applications use databases to store and manage information such as users, products, orders, messages, and authentication data.

For anyone learning web penetration testing, understanding databases and SQL is essential because many web applications rely on SQL queries to process user input.

This guide covers the fundamental concepts of databases, SQL, DBMS, database structure, CRUD operations, filtering, operators, functions, and relationships between tables.

1. What is a Database?

A database is an organized collection of data that can be stored, accessed, managed, and analyzed.

Databases are used in many types of applications, including:

• Authentication systems
• Social media platforms
• Streaming services
• E-commerce websites
• Banking systems
• Content management systems
• Web applications

A simplified web application architecture looks like:

User
  ↓
Web Application
  ↓
Database
  ↓
Stored Data

For example, an e-commerce application might store:

Users
Products
Orders
Payments
Addresses

2. Types of Databases

There are two major categories worth understanding at the beginner level:

Relational Databases — SQL

Relational databases store structured data using tables.

A table consists of:

Rows
Columns

Examples include:

• MySQL
• MariaDB
• PostgreSQL
• Oracle Database
• Microsoft SQL Server
• SQLite

Relational databases are commonly used when data has clearly defined relationships and structures.

Examples:

Users
Products
Orders
Customers
Transactions

Non-Relational Databases — NoSQL

NoSQL databases do not necessarily use traditional tables, rows, and columns.

They can store data using formats such as:

• Documents
• Key-value pairs
• Graphs
• Wide-column structures

Examples include:

• MongoDB
• Redis
• Cassandra

NoSQL databases are useful when applications need flexible data structures or specific scalability models.

Important distinction

SQL
→ Usually structured relational data

NoSQL
→ Flexible non-relational data models

NoSQL does not simply mean “no structure”; it means the database does not primarily follow the traditional relational model.

3. Tables, Rows, and Columns

Understanding the structure of a relational database is essential.

Table

A table is a collection of related data.

Example:

Books
--------------------------------
id | name | author
--------------------------------
1  | Book A | Author 1
2  | Book B | Author 2
3  | Book C | Author 3

Column

A column defines an attribute of the stored data.

Examples:

id
name
email
author
price

Each column normally has a specific data type.

Row

A row represents one complete record.

For example:

1 | Book A | Author 1

is one row in the Books table.

4. Common Data Types

Databases support different types of data.

Common examples include:

String

Used for text.

Alice
hello@example.com
Book A

Integer

Used for whole numbers.

1
25
100

Float / Decimal

Used for numbers containing decimal values.

19.99
3.14
99.50

Date / Time

Used for dates and timestamps.

2026-09-20
2026-09-20 14:30:00

The exact data types available can vary between database systems.

5. Primary Keys

A Primary Key (PK) uniquely identifies a row in a table.

Example:

Books
-------------------
id (PK)
-------------------
1
2
3

The primary key should uniquely identify each record.

Important characteristics:

• Uniquely identifies a record
• Cannot contain duplicate values
• A table has one primary key constraint
• It can consist of one column or multiple columns

For a simple example:

id | name
-----------
1  | Book A
2  | Book B
3  | Book C

The id column identifies each book.

6. Foreign Keys

A Foreign Key (FK) creates a relationship between tables.

For example:

Books
----------------
id
author_id  ← FK

and:

Authors
----------------
id  ← PK
name

The relationship can be represented as:

Books.author_id
       |
       ↓
Authors.id

A foreign key usually references a primary key or another candidate key in another table.

Unlike a primary key, a foreign key can contain repeated values because multiple records may reference the same record.

7. Primary Key vs Foreign Key

Primary KeyForeign KeyUniquely identifies a recordReferences a record in another tableEnforces uniquenessDoes not have to be uniqueUsed to identify rowsUsed to create relationshipsOne primary key constraint per tableMultiple foreign key constraints can existCommonly referenced by foreign keysCommonly references another table’s key

Easy way to remember

PK = Unique identifier

FK = Link between tables

8. What is SQL?

SQL stands for Structured Query Language.

It is used to communicate with relational database systems.

SQL can be used to:

• Retrieve data
• Insert data
• Update data
• Delete data
• Create databases
• Create tables
• Modify tables
• Manage database structures

Example:

SELECT * FROM users;

This asks the database to return all columns from the users table.

9. What is a DBMS?

DBMS stands for Database Management System.

A DBMS is software used to create, manage, store, and interact with databases.

Examples include:

• MySQL
• MariaDB
• PostgreSQL
• Oracle Database
• Microsoft SQL Server
• SQLite
• MongoDB

One important distinction:

Database
= Stored data

DBMS
= Software that manages the database

SQL
= Language used to communicate with a relational DBMS

MongoDB is a DBMS, but it is a NoSQL database system rather than a traditional relational SQL DBMS.

10. Connecting to MySQL

A common MySQL login command is:

mysql -u root -p

The options mean:

-u
→ Specify username

root
→ Username

-p
→ Prompt for password

After successful authentication, you may see:

mysql>

This indicates that you are inside the MySQL command-line client.

11. Creating a Database

To create a database:

CREATE DATABASE database_name;

For example:

CREATE DATABASE library;

This creates a database called library.

12. Listing Databases

To display available databases:

SHOW DATABASES;

Example output might include:

information_schema
library
mysql
performance_schema

13. Selecting a Database

Before working with tables inside a database, select it:

USE database_name;

Example:

USE library;

You are now working with the library database.

14. Deleting a Database

A database can be permanently removed using:

DROP DATABASE database_name;

Example:

DROP DATABASE library;

Important: DROP DATABASE permanently removes the database and its contents.

15. Creating a Table

A table can be created with:

CREATE TABLE table_name (
    column_name data_type
);

For example:

CREATE TABLE books (
    id INT,
    name VARCHAR(100),
    price DECIMAL(10,2)
);

This creates a table containing:

id
name
price

16. Showing Tables

To list the tables in the currently selected database:

SHOW TABLES;

17. Describing a Table

To inspect the structure of a table:

DESCRIBE books;

or:

DESC books;

This can show information such as:

• Column names
• Data types
• Keys
• Whether NULL values are allowed
• Default values
• Additional attributes

This is an important command when performing database enumeration.

18. Altering a Table

The ALTER TABLE statement modifies an existing table.

For example:

ALTER TABLE books
ADD description TEXT;

This adds a new description column.

19. Dropping a Table

To permanently delete a table:

DROP TABLE books;

This removes the table and its data.

20. CRUD Operations

CRUD represents the four fundamental operations performed on data.

C = Create
R = Read
U = Update
D = Delete

These correspond to:

INSERT
SELECT
UPDATE
DELETE

21. CREATE — INSERT

The INSERT statement adds a new record.

Example:

INSERT INTO books
(id, name)
VALUES (1, 'Book A');

Multiple values can also be inserted:

INSERT INTO books (id, name)
VALUES
(1, 'Book A'),
(2, 'Book B'),
(3, 'Book C');

22. READ — SELECT

The SELECT statement retrieves data.

To retrieve everything:

SELECT * FROM books;

The * means all columns.

To retrieve specific columns:

SELECT name, price
FROM books;

This returns only the selected columns.

23. UPDATE

The UPDATE statement modifies existing records.

Example:

UPDATE books
SET name = 'New Book'
WHERE id = 1;

The WHERE clause is important because it specifies which record should be modified.

Without an appropriate WHERE condition, an UPDATE statement can affect multiple or all rows.

24. DELETE

The DELETE statement removes records.

Example:

DELETE FROM books
WHERE id = 1;

Again, the WHERE clause determines which rows are deleted.

Without a WHERE clause:

DELETE FROM books;

all rows in the table may be deleted.

25. WHERE Clause

The WHERE clause filters records based on a condition.

Example:

SELECT *
FROM books
WHERE id = 1;

This returns only records where the id is 1.

WHERE is one of the most important SQL concepts because it controls which records are affected by a query.

26. Comparison Operators

SQL provides operators for comparing values.

OperatorMeaning=Equal!=Not equal<>Not equal<Less than>Greater than<=Less than or equal>=Greater than or equal

Examples:

SELECT * FROM books WHERE price > 20;

SELECT * FROM books WHERE id != 5;

27. AND

AND requires all conditions to be true.

Example:

SELECT *
FROM books
WHERE price > 10 AND price < 50;

Both conditions must be satisfied.

28. OR

OR requires at least one condition to be true.

Example:

SELECT *
FROM books
WHERE id = 1 OR id = 2;

The result can contain records matching either condition.

29. NOT

NOT reverses a condition.

Example:

SELECT *
FROM books
WHERE NOT id = 1;

This selects records where the condition is not true.

30. BETWEEN

BETWEEN checks whether a value falls within a range.

Example:

SELECT *
FROM books
WHERE id BETWEEN 2 AND 4;

This selects values within the specified range.

31. LIKE

LIKE is used for pattern matching.

For example:

SELECT *
FROM books
WHERE name LIKE '%book%';

The % wildcard represents zero or more characters.

Common patterns include:

LIKE 'book%'

Starts with book.

LIKE '%book'

Ends with book.

LIKE '%book%'

Contains book.

32. DISTINCT

DISTINCT removes duplicate values from the result.

Example:

SELECT DISTINCT author
FROM books;

Instead of showing the same author multiple times, SQL returns each unique value once.

33. ORDER BY

ORDER BY sorts query results.

Example:

SELECT *
FROM books
ORDER BY price;

By default, the results are generally sorted in ascending order.

For descending order:

SELECT *
FROM books
ORDER BY price DESC;

For ascending order:

SELECT *
FROM books
ORDER BY price ASC;

34. LIMIT

LIMIT restricts the number of rows returned.

Example:

SELECT *
FROM books
LIMIT 5;

This returns up to five rows.

It is useful when working with large datasets.

35. NULL Values

NULL represents a missing or unknown value.

It is important to understand that:

NULL ≠ 0

NULL ≠ ''

NULL ≠ FALSE

To check for NULL values, use:

SELECT *
FROM users
WHERE email IS NULL;

To find values that are not NULL:

SELECT *
FROM users
WHERE email IS NOT NULL;

You should not normally use:

WHERE email = NULL

because NULL requires IS NULL or IS NOT NULL.

36. String Functions

SQL provides functions for manipulating text.

CONCAT()

Combines strings.

SELECT CONCAT(first_name, ' ', last_name)
FROM users;

GROUP_CONCAT()

Combines values from multiple rows into a single string in database systems that support it, such as MySQL.

Example:

SELECT GROUP_CONCAT(name)
FROM users;

SUBSTRING()

Extracts part of a string.

Example:

SELECT SUBSTRING('Cybersecurity', 1, 4);

This extracts a portion of the string.

LENGTH()

Returns the length of a string.

Example:

SELECT LENGTH('Cybersecurity');

37. Aggregate Functions

Aggregate functions perform calculations across multiple rows.

COUNT()

Counts rows.

SELECT COUNT(*)
FROM users;

SUM()

Adds numeric values.

SELECT SUM(price)
FROM products;

MAX()

Returns the largest value.

SELECT MAX(price)
FROM products;

MIN()

Returns the smallest value.

SELECT MIN(price)
FROM products;

Another important aggregate function is:

AVG()

Calculates the average value.

SELECT AVG(price)
FROM products;

38. GROUP BY

GROUP BY groups rows that have the same value.

For example:

SELECT author, COUNT(*)
FROM books
GROUP BY author;

This can show how many books belong to each author.

A simplified result could look like:

Author  | COUNT
----------------
Alice   | 3
Bob     | 5
Charlie | 2

39. HAVING

HAVING filters grouped results.

Example:

SELECT author, COUNT(*)
FROM books
GROUP BY author
HAVING COUNT(*) > 2;

The important difference is:

WHERE
→ Filters rows before grouping

HAVING
→ Filters groups after grouping

40. SQL JOINs

Relational databases are designed around relationships between tables.

JOIN statements allow data from multiple tables to be combined.

Suppose we have:

Users
----------------
id
name

and:

Orders
----------------
id
user_id
product

The user_id can reference Users.id.

INNER JOIN

Returns matching records from both tables.

SELECT users.name, orders.product
FROM users
INNER JOIN orders
ON users.id = orders.user_id;

LEFT JOIN

Returns all rows from the left table and matching rows from the right table.

SELECT users.name, orders.product
FROM users
LEFT JOIN orders
ON users.id = orders.user_id;

If a user has no matching order, the order fields can contain NULL.

41. SQL Comments

SQL supports comments, although the exact syntax can vary between database systems.

A common single-line comment syntax is:

-- comment

MySQL also supports:

# comment

Comments are useful when documenting SQL queries and understanding existing database code.

42. SQL Statement Structure

A basic SQL query often follows this structure:

SELECT column
FROM table
WHERE condition
ORDER BY column
LIMIT number;

For example:

SELECT name, price
FROM books
WHERE price > 20
ORDER BY price DESC
LIMIT 5;

This query:

1. Selects name and price
2. From the books table
3. Keeps books costing more than 20
4. Sorts them from highest to lowest price
5. Returns up to five results

43. SQL Fundamentals for Web Security

Understanding SQL is especially important for web penetration testing.

A typical web application might receive input:

/search?id=10

The application could use that value in a database query.

Conceptually:

HTTP Request
     ↓
Web Application
     ↓
SQL Query
     ↓
Database
     ↓
Response

If developers incorrectly construct SQL queries using untrusted input, SQL Injection may become possible.

This is why learning SQL fundamentals should come before learning tools such as SQLMap.

You should understand what the application is doing before trying to automate the testing.

44. SQL vs SQL Injection

These concepts should not be confused.

SQL

A legitimate language used to communicate with relational databases.

SQL Injection

A security vulnerability that occurs when untrusted input can improperly influence an SQL query.

SQL
→ Language

SQL Injection
→ Vulnerability

SQL itself is not a vulnerability.

45. Quick SQL Cheat Sheet

Database

CREATE DATABASE database_name;
SHOW DATABASES;
USE database_name;
DROP DATABASE database_name;

Tables

CREATE TABLE table_name (...);
SHOW TABLES;
DESCRIBE table_name;
ALTER TABLE table_name ...;
DROP TABLE table_name;

CRUD

INSERT INTO table_name (...) VALUES (...);

SELECT * FROM table_name;

UPDATE table_name
SET column = value
WHERE condition;

DELETE FROM table_name
WHERE condition;

Filtering

WHERE
AND
OR
NOT
LIKE
BETWEEN

Sorting and Limiting

ORDER BY
LIMIT
DISTINCT

Aggregation

COUNT()
SUM()
AVG()
MAX()
MIN()
GROUP BY
HAVING

Relationships

JOIN
INNER JOIN
LEFT JOIN

String Functions

CONCAT()
GROUP_CONCAT()
SUBSTRING()
LENGTH()

Key Takeaways

After studying SQL Fundamentals, I should be able to explain:

• What a database is
• The difference between SQL and NoSQL
• What a relational database is
• What tables, rows, and columns represent
• What primary and foreign keys are
• What SQL is
• What a DBMS is
• How to connect to MySQL
• How to create and manage databases
• How to create and manage tables
• How CRUD operations work
• How SELECT retrieves data
• How WHERE filters data
• How comparison and logical operators work
• How LIKE performs pattern matching
• How ORDER BY sorts results
• How LIMIT restricts results
• How DISTINCT removes duplicates
• How NULL values work
• How aggregate functions work
• How GROUP BY and HAVING work
• How tables can be connected using JOINs
• Why SQL knowledge is important for web penetration testing

Conclusion

SQL fundamentals are an important foundation for anyone interested in web security and penetration testing.

Before studying SQL Injection or using automated tools such as SQLMap, it is important to understand how databases are structured and how SQL queries work.

The core concepts to remember are:

Database
→ Stores data

DBMS
→ Manages the database

SQL
→ Communicates with relational databases

Table
→ Stores related records

Row
→ Represents one record

Column
→ Represents an attribute

Primary Key
→ Uniquely identifies a record

Foreign Key
→ Creates a relationship between tables

CRUD
→ Create, Read, Update, Delete

Once these fundamentals are clear, topics such as SQL Injection, SQLMap, database enumeration, and web application security become much easier to understand.

Main lesson: don’t memorize SQL commands only. Understand what each query does to the database and why the result changes depending on the conditions you provide.

Introduction

Web applications often expose resources that are not directly linked from the main page. Directories, files, subdomains, and virtual hosts may exist on a web server without being immediately visible to a user.

This is where web enumeration becomes useful.

In this TryHackMe room, I explored Gobuster, a command-line tool commonly used for discovering hidden web resources during authorized security assessments.

The room introduces Gobuster’s basic syntax, wordlists, directory and file enumeration, subdomain enumeration, and virtual host enumeration.

Platform: TryHackMe
Room: Gobuster: The Basics
Difficulty: Beginner
Focus: Web Enumeration

1. What is Gobuster?

Gobuster is a command-line enumeration tool written in Go.

It can be used to discover resources such as:

• Directories
• Files
• Subdomains
• Virtual hosts

The basic idea is to provide Gobuster with a target and a wordlist.

Gobuster then takes entries from the wordlist and makes requests based on them.

A simplified workflow looks like this:

Wordlist
   ↓
Gobuster
   ↓
Target Web Server
   ↓
HTTP Requests
   ↓
Discovered Resources

For example, if a wordlist contains:

admin
login
images
backup

Gobuster can test whether resources corresponding to these names exist on the target.

2. Why Web Enumeration Matters

When performing a web application security assessment, the homepage is usually only one part of the application.

A web server might contain additional resources such as:

/admin
/login
/uploads
/backup
/config

Some of these resources may not be linked from the homepage.

Enumeration helps security testers build a better understanding of the application’s attack surface.

Security relevance

Discovering hidden resources does not automatically mean they are vulnerable.

The purpose of enumeration is to identify what exists so that it can be investigated further.

3. Gobuster Help

Before using a command-line security tool, it is useful to understand its available options.

Gobuster provides a help menu:

gobuster --help

It can also provide help for a specific mode.

For example:

gobuster dir --help

This displays the options available for directory enumeration.

Reading the help output is an important habit because tool syntax and options can vary between versions.

4. Gobuster Modes

Gobuster provides different enumeration modes.

The room focuses on three important modes:

dir
dns
vhost

dir

Used for discovering directories and files on a web server.

dns

Used for DNS subdomain enumeration.

vhost

Used for discovering virtual hosts configured on a web server.

Each mode has a different purpose, but the underlying idea is similar: use a wordlist to test possible resources.

5. Directory Enumeration

One of the most common uses of Gobuster is directory enumeration.

The mode is:

dir

A basic structure is:

gobuster dir -u http://TARGET -w WORDLIST

Here:

• dir selects directory enumeration
• -u specifies the target URL
• -w specifies the wordlist

For example:

gobuster dir -u http://TARGET -w wordlist.txt

Gobuster then tests words from the wordlist against the target.

6. Understanding Directory Enumeration

Suppose the wordlist contains:

admin
login
images
uploads
backup

Gobuster may test requests such as:

/admin
/login
/images
/uploads
/backup

If the server responds differently because a resource exists, Gobuster reports the result.

This can reveal directories that were not visible from the main website.

7. HTTP Status Codes

When enumerating a website, understanding HTTP status codes is important.

Some common examples include:

200 — OK

The requested resource was successfully returned.

301 — Moved Permanently

The requested resource redirects to another location.

302 — Found

The server redirects the client to another location.

403 — Forbidden

The server understood the request but refuses to provide access.

404 — Not Found

The requested resource does not exist.

Gobuster can display these status codes alongside discovered resources.

Security relevance

A 403 response can still be interesting during enumeration.

It may indicate that a resource exists even though direct access is currently forbidden.

8. File Enumeration

Gobuster can also search for files.

This can be done by specifying file extensions with the appropriate option.

For example:

gobuster dir -u http://TARGET -w wordlist.txt -x php,txt,html

The -x option tells Gobuster which extensions to test.

Instead of checking only:

/admin

Gobuster can also test:

/admin.php
/admin.txt
/admin.html

The exact extensions should depend on the technology being assessed.

9. Wordlists

Wordlists are a key component of Gobuster.

A wordlist contains potential names that Gobuster will test against the target.

For example:

admin
login
dashboard
uploads
images
backup

The larger and more relevant the wordlist, the more potential resources can be tested.

However, larger wordlists also mean more requests and potentially longer enumeration times.

Security perspective

A good penetration tester chooses wordlists based on the target rather than blindly using the largest available list.

For example, technology-specific or application-specific wordlists can sometimes produce better results.

10. Subdomain Enumeration

Web applications may use multiple subdomains.

For example:

www.example.com
admin.example.com
api.example.com
dev.example.com

Some subdomains may expose completely different applications or services.

Gobuster provides a DNS enumeration mode:

dns

A basic structure is:

gobuster dns -d example.com -w wordlist.txt

Here:

• dns selects DNS enumeration
• -d specifies the domain
• -w specifies the wordlist

Gobuster then tests potential subdomain names.

11. Why Subdomain Enumeration Matters

Organizations often separate applications across different subdomains.

For example:

www.example.com
api.example.com
dev.example.com
mail.example.com

The main website may have strong security controls while another subdomain could expose a development application or administrative interface.

Therefore, discovering subdomains can significantly expand the known attack surface.

Important distinction

Finding a subdomain does not mean that it is vulnerable.

It simply gives the tester another asset to investigate.

12. Virtual Host Enumeration

Another concept covered by the room is Virtual Host (VHost) enumeration.

A single web server can host multiple websites.

The server can determine which website the client wants based on the HTTP Host header.

For example:

Host: www.example.com

could return one application, while:

Host: admin.example.com

could return another.

Gobuster provides the:

vhost

mode for this type of enumeration.

A basic structure is:

gobuster vhost -u http://example.com -w wordlist.txt

Gobuster tests potential virtual host names and analyzes the server’s responses.

13. Subdomains vs Virtual Hosts

These two concepts are easy to confuse.

Subdomain Enumeration

Looks for DNS records such as:

admin.example.com
dev.example.com
api.example.com

The goal is to discover subdomains that resolve through DNS.

VHost Enumeration

Tests different hostnames against a web server to identify virtual hosts configured on that server.

A hostname may be configured on the web server even if it is not publicly listed as a normal DNS record.

Therefore, DNS enumeration and VHost enumeration can reveal different information.

14. Useful Gobuster Options

Some commonly used options include:

-u

Specifies the target URL.

-w

Specifies the wordlist.

-x

Specifies file extensions to test.

-t

Controls the number of concurrent threads.

-o

Saves the output to a file.

The available options depend on the Gobuster mode being used.

15. Enumeration Workflow

A simple web enumeration workflow can look like this:

Step 1 — Identify the target

Determine the authorized target URL or domain.

Step 2 — Choose a suitable wordlist

Select a wordlist appropriate for the target.

Step 3 — Enumerate directories

Use:

gobuster dir -u http://TARGET -w WORDLIST

Step 4 — Enumerate files

Add relevant extensions:

gobuster dir -u http://TARGET -w WORDLIST -x php,txt,html

Step 5 — Enumerate subdomains

Use DNS enumeration:

gobuster dns -d example.com -w WORDLIST

Step 6 — Test virtual hosts

Use:

gobuster vhost -u http://example.com -w WORDLIST

Step 7 — Investigate discoveries

After finding a resource, investigate it manually and determine whether it is expected, accessible, or potentially interesting from a security perspective.

16. Why Enumeration Should Come Before Exploitation

One of the most important lessons from this room is that enumeration should happen before attempting to exploit a target.

A tester needs to understand the attack surface first.

For example:

Reconnaissance
      ↓
Enumeration
      ↓
Identify Technologies
      ↓
Discover Resources
      ↓
Analyze Potential Issues
      ↓
Security Testing

Without proper enumeration, important resources may remain undiscovered.

17. Defensive Perspective

Gobuster is primarily an offensive-security tool, but understanding how it works is also useful for defenders.

Organizations can reduce exposure by:

• Removing unnecessary files
• Removing unused directories
• Restricting administrative interfaces
• Avoiding exposed backup files
• Properly configuring virtual hosts
• Monitoring unusual HTTP request patterns
• Using appropriate access controls

For example, sensitive administrative interfaces should not be unnecessarily exposed to the public Internet.

Key Takeaways

After completing the Gobuster room, I learned:

• What Gobuster is
• Why web enumeration is important
• How wordlists are used
• How to enumerate directories
• How to enumerate files
• How HTTP status codes help identify resources
• How to perform DNS subdomain enumeration
• How virtual host enumeration works
• The difference between subdomains and virtual hosts
• How Gobuster options modify enumeration
• Why enumeration should happen before exploitation
• How defenders can reduce unnecessary web exposure

Conclusion

Gobuster is a useful enumeration tool for discovering resources that may not be immediately visible on a web application.

The room demonstrates three important areas of enumeration:

Directory/File Enumeration
        +
DNS Enumeration
        +
Virtual Host Enumeration

Understanding these techniques is an important part of web penetration testing because they help security professionals map an application’s attack surface.

The most important lesson is that enumeration is about discovering and understanding the target before attempting further security testing.

Gobuster does not automatically identify vulnerabilities. Instead, it helps reveal resources that can then be analyzed manually or with other security tools.

Main lesson: a good penetration test starts with thorough enumeration because you cannot properly assess what you have not discovered.

Linux Fundamentals Part 1 — TryHackMe Write-Up

Introduction

Linux is one of the most important operating systems to understand in cybersecurity. It is widely used in servers, cloud infrastructure, networking, security tools, and penetration-testing environments.

For someone starting in cybersecurity, learning how to navigate Linux and use the command line is an essential foundation.

In this TryHackMe room, I explored the basics of Linux, including distributions, the Linux terminal, filesystem navigation, file searching, and shell operators.

Platform: TryHackMe
Room: Linux Fundamentals Part 1
Difficulty: Beginner
Focus: Linux Command Line Fundamentals

1. What is Linux?

Linux is an open-source operating system kernel that forms the foundation of many operating systems known as Linux distributions.

Unlike Windows, Linux is commonly interacted with through the command line, although graphical desktop environments are also available.

Linux is widely used in:

• Servers
• Cloud environments
• Networking
• Cybersecurity
• Embedded systems
• Development environments

For cybersecurity professionals, Linux knowledge is especially useful because many security tools and testing environments are built around Linux.

2. Linux Distributions

Linux itself is a kernel. A Linux distribution, or distro, combines the Linux kernel with other software to create a complete operating system.

Examples include:

• Ubuntu
• Debian
• Fedora
• Arch Linux
• Kali Linux

Different distributions are designed for different purposes.

For example, Kali Linux is specifically designed for penetration testing and security research.

Understanding different distributions is useful because commands and package-management systems can vary between them.

3. The Linux Terminal

The terminal provides a way to interact with Linux through commands.

Instead of clicking through graphical interfaces, users can type commands to perform actions.

A shell interprets the commands entered by the user and communicates with the operating system.

One common shell is:

Bash

The command line is extremely important in cybersecurity because many security tasks can be performed more efficiently through a terminal.

4. Basic Linux Commands

The room introduces several commands that are essential for navigating Linux.

echo

The echo command prints text to the terminal.

Example:

echo Hello

This produces:

Hello

It can also be used with variables and command output.

whoami

The whoami command displays the username of the current user.

whoami

This is useful when you need to determine which account you are currently using.

Security relevance

Knowing the current user is important because permissions and access depend on the account.

5. Navigating the Filesystem

Linux uses a hierarchical filesystem.

At the top is the root directory:

/

Everything else exists somewhere below this directory.

Important directories include:

/home
/etc
/var
/tmp
/usr
/root

Each directory has a specific purpose.

6. Listing Files with ls

The ls command displays the contents of a directory.

ls

It can also be combined with options.

For example:

ls -l

The -l option provides a more detailed listing.

Another useful option is:

ls -la

This also displays hidden files.

Security relevance

Being able to list files and understand permissions is fundamental when performing Linux enumeration.

7. Changing Directories with cd

The cd command is used to move between directories.

For example:

cd /home

moves into the /home directory.

To move to the parent directory:

cd ..

To return to the home directory:

cd ~

The cd command is one of the most frequently used commands when navigating Linux.

8. Finding Your Current Location with pwd

The pwd command stands for:

Print Working Directory

Example:

pwd

It displays the full path of the directory you are currently inside.

For example:

/home/user

This is useful when navigating through a large filesystem because it tells you exactly where you are.

9. Reading Files with cat

The cat command can be used to display the contents of a file.

Example:

cat file.txt

The contents of the file are printed directly to the terminal.

This command is commonly used when reading configuration files, text files, and other small files.

10. Searching for Files with find

Linux provides the find command for searching the filesystem.

A basic example is:

find / -name filename

This searches for a file with a specific name.

Another example:

find /home -name "*.txt"

This searches for .txt files inside /home.

Security relevance

The find command is extremely useful during Linux enumeration.

A security professional may use it to locate:

• Configuration files
• Scripts
• Interesting directories
• Files with specific names
• Potentially sensitive data

11. Searching Text with grep

The grep command searches for specific text inside files.

For example:

grep "password" file.txt

This searches the file for occurrences of the word password.

It can also be combined with other commands.

For example:

cat file.txt | grep "admin"

This sends the output of cat to grep.

Security relevance

grep is extremely useful for searching configuration files, logs, source code, and other text-based data.

12. Shell Operators

The room introduces several shell operators that allow commands to be combined or their output redirected.

These operators are important because they make the Linux command line much more powerful.

The & Operator

The & operator can be used to run a command in the background.

Example:

command &

This allows the shell to continue accepting commands while the previous process runs.

The && Operator

The && operator runs the second command only if the first command succeeds.

Example:

command1 && command2

This is useful when commands depend on the successful completion of previous commands.

The > Operator

The > operator redirects command output into a file.

Example:

echo "Hello" > file.txt

If the file already exists, its contents are overwritten.

The >> Operator

The >> operator also redirects output to a file, but appends the output instead of replacing the existing content.

Example:

echo "Another line" >> file.txt

This adds the new content to the end of the file.

The | Operator

The pipe operator sends the output of one command into another command.

Example:

cat file.txt | grep "admin"

Here:

cat
 ↓
file contents
 ↓
grep
 ↓
matching lines

Pipes are extremely important in Linux because they allow multiple simple commands to be combined into more powerful workflows.

13. Why the Command Line Matters in Cybersecurity

The Linux command line is one of the most important skills for cybersecurity professionals.

Many security activities require working with:

• Files
• Processes
• Logs
• Network information
• Permissions
• Configuration files

Instead of manually navigating through a graphical interface, command-line tools allow security professionals to perform tasks quickly and automate repetitive operations.

For example:

whoami
pwd
ls
find
grep

These are simple commands, but they form the foundation for much more advanced Linux enumeration.

14. Practical Enumeration Workflow

The commands introduced in this room can already be combined into a simple workflow.

For example:

whoami
pwd
ls -la

This can help answer three basic questions:

1. Who am I?
2. Where am I?
3. What files are here?

Then, commands such as:

find
grep
cat

can be used to investigate files and their contents.

This simple workflow becomes much more important in later penetration-testing and Linux privilege-escalation rooms.

Key Takeaways

After completing Linux Fundamentals Part 1, I learned:

• What Linux and Linux distributions are
• Why Linux is important in cybersecurity
• How to use the terminal
• How to identify the current user with whoami
• How to navigate directories with cd
• How to list files with ls
• How to identify the current directory with pwd
• How to read files with cat
• How to search for files with find
• How to search text with grep
• How shell operators work
• How to redirect output
• How to combine commands using pipes

Conclusion

Linux Fundamentals Part 1 provides the basic command-line knowledge required to work comfortably in a Linux environment.

The commands introduced in this room may appear simple, but they are fundamental to cybersecurity. Commands such as ls, cd, pwd, find, and grep are regularly used during system administration, troubleshooting, enumeration, and security investigations.

The most important lesson is that mastering Linux starts with understanding the filesystem and becoming comfortable with the command line.

These fundamentals provide the foundation for more advanced topics such as Linux permissions, privilege escalation, networking, system administration, and penetration testing.

Main lesson: before learning advanced Linux security techniques, become comfortable navigating the filesystem and combining basic commands through the terminal.

Introduction

Password security is an important part of cybersecurity. Weak or predictable passwords can make accounts vulnerable to automated guessing attacks.

In this TryHackMe room, I explored Hydra, a popular command-line tool used to perform automated password guessing against network authentication services.

The room demonstrates how Hydra works and how it can be used in a controlled lab environment against services such as SSH and web login forms.

Platform: TryHackMe
Room: Hydra
Difficulty: Easy
Focus: Password Attacks and Hydra

1. What is Hydra?

Hydra is a command-line password-cracking tool designed to perform automated login attempts against supported network services.

Instead of manually testing passwords one by one, Hydra can automate the process using a username and a wordlist.

The general idea is:

Username
   +
Password Wordlist
   ↓
Hydra
   ↓
Authentication Attempts
   ↓
Potential Valid Credentials

Hydra supports many different protocols and services, making it a useful tool for security testing in authorized environments.

Useful Resource: https://github.com/vanhauser-thc/thc-hydra

Additional Resource : https://en.kali.tools/?p=220#google_vignette

2. Why Password Attacks Matter

Passwords are still widely used for authentication.

If a password is weak, predictable, or reused, an attacker may be able to guess it.

Automated tools make this process much faster than manually trying credentials.

This is why organizations should use:

• Strong passwords
• Multi-factor authentication
• Account lockout policies
• Rate limiting
• Monitoring and logging

From a penetration-testing perspective, testing password strength can help identify weak authentication controls.

3. Hydra Syntax

Hydra follows a relatively simple command structure.

A basic syntax looks like:

hydra [options] TARGET SERVICE

Hydra can also be supplied with usernames and password wordlists.

For example, the room introduces the use of:

-l

for a single username,

and:

-P

for a password wordlist.

The target and service are then specified.

4. Password Wordlists

A wordlist is a file containing possible passwords.

Instead of generating passwords randomly, Hydra can read candidate passwords from a wordlist and test them against the target service.

A common wordlist used in security labs is:

/usr/share/wordlists/rockyou.txt

The wordlist contains a large collection of commonly used passwords.

Security relevance

Wordlists demonstrate why password complexity matters.

If a user’s password appears in a commonly used password list, automated password guessing may be able to discover it.

5. Hydra Against SSH

The room demonstrates using Hydra against an SSH service.

SSH, or Secure Shell, provides remote command-line access to a system.

The relevant Hydra module is:

ssh

A typical lab command follows the structure:

hydra -l <username> -P <wordlist> ssh://<target>

Here:

• -l specifies the username
• -P specifies the password wordlist
• ssh:// specifies the SSH service
• <target> represents the authorized lab machine

Hydra then attempts the passwords from the wordlist against the SSH authentication service.

Security lesson

If a weak password is accepted by a remotely accessible SSH service, the account may be exposed to automated password guessing.

This demonstrates why SSH servers should use strong authentication controls and appropriate access restrictions.

6. Understanding Hydra Output

When Hydra performs authentication attempts, it displays information about its progress.

If valid credentials are discovered, Hydra reports the successful combination.

The important part of the result is the relationship between:

Username
+
Password
+
Target

A successful result means that the tested credentials were accepted by the target service.

In a real penetration test, this information would need to be handled carefully because credentials are sensitive information.

7. Hydra and HTTP Login Forms

The room also introduces password guessing against an HTTP POST login form.

Web applications often authenticate users through forms.

A simplified login process looks like:

Username + Password
        ↓
HTTP POST Request
        ↓
Web Application
        ↓
Authentication Result

Hydra can automate attempts against certain HTTP forms when the required parameters are known.

8. HTTP POST Forms

A POST request can contain login parameters such as:

username=<username>
password=<password>

The application then processes these values and returns a response.

For Hydra to work correctly against a form, the tester needs to understand:

• The login page
• The HTTP method
• The submitted parameters
• The failure response

This information allows Hydra to determine whether an authentication attempt succeeded or failed.

9. Identifying a Failed Login

One important concept when attacking a web login form is identifying how the application indicates failure.

For example, the server may return a message such as:

Invalid username or password

Hydra can use a failure string to distinguish unsuccessful attempts from successful ones.

This is important because Hydra needs some way to determine whether the credentials it tested were accepted.

10. Hydra Options

Some useful Hydra options include:

-l

Specifies a single username.

-L

Specifies a file containing multiple usernames.

-p

Specifies a single password.

-P

Specifies a password wordlist.

-v

Enables verbose output.

-f

Stops after finding a valid login.

The exact options used depend on the target service and the testing requirements.

11. Hydra in a Controlled Environment

Hydra is a powerful tool, but password-guessing attacks should only be performed against systems where you have explicit authorization.

In the TryHackMe environment, the target is intentionally provided for security training.

This makes the lab useful for understanding:

• How authentication works
• How wordlists are used
• How automated guessing works
• How weak passwords can be discovered
• How defensive controls can reduce password attacks

12. Defensive Perspective

Learning Hydra is not only about attacking authentication.

It also helps understand how to defend against automated password guessing.

Organizations can reduce the risk by implementing:

Strong Passwords

Passwords should be long and difficult to guess.

Multi-Factor Authentication

MFA adds another authentication factor beyond the password.

Rate Limiting

Applications can limit the number of authentication attempts.

Account Lockout

Repeated failed authentication attempts can trigger temporary account restrictions.

Monitoring

Security teams can monitor authentication logs for unusual numbers of failed login attempts.

Network Restrictions

Services such as SSH should not necessarily be exposed to every network or user.

13. Key Takeaways

After completing the Hydra room, I learned:

• What Hydra is and what it is used for
• How password wordlists work
• How Hydra can test authentication services
• How Hydra can interact with SSH
• How HTTP POST login forms work
• Why identifying failed-login responses matters
• How Hydra options control authentication attempts
• Why weak passwords create security risks
• How defensive controls can reduce automated password attacks

Conclusion

The Hydra room demonstrates how automated password guessing works in a controlled penetration-testing environment.

Hydra makes it possible to automate authentication attempts against supported services instead of manually testing credentials.

The most important lesson is that password security is not only about choosing a strong password. Organizations should also use MFA, rate limiting, account protection, monitoring, and proper network restrictions to reduce the effectiveness of automated authentication attacks.

Understanding tools such as Hydra gives penetration testers a practical way to evaluate authentication security while also helping defenders understand how these attacks can be detected and prevented.

Main lesson: strong authentication controls are essential because automated tools can test large numbers of credential combinations much faster than a human can.