Post cover image

October 15, 2026

Frontend ↔ Backend Communication: A Security-Focused Guide

A practical reference for Web Pentesting and Bug Bounty Hunting

By Mohamed Algabry

18 min read

Legal and ethical notice:_ Test only systems you own or are explicitly authorized to assess. Use test accounts and test data, follow the program scope and rules, and avoid service disruption or access to real users' data._

Introduction: Five Ways Frontend and Backend Communicate?

More precisely, these are communication technologies, interfaces, and patterns — -not five separate programming languages:

  • REST API: An architectural style for HTTP APIs, commonly using JSON.
  • GraphQL: A query language and specification for APIs.
  • WebSocket: A protocol for persistent, bidirectional communication.
  • SSE (Server-Sent Events): A way to stream events from a server to a client over HTTP.
  • gRPC: A Remote Procedure Call framework that commonly uses Protocol Buffers and HTTP/2.

These technologies are not interchangeable in every situation. An application might use REST for data retrieval, WebSocket for real-time notifications, SSE for task progress, GraphQL for flexible data queries, and gRPC between backend services.

How to Think Like a Pentester

For every communication channel, ask:

  1. How is the user's identity verified? (Authentication)
  2. Is that identity allowed to perform this action on this resource? (Authorization)
  3. How is data converted to and from bytes and objects? (Serialization / Deserialization)
  4. Are inputs and outputs validated and handled safely? (Input Validation / Output Encoding)
  5. Are usage and resource costs limited? (Rate Limiting / Resource Controls)
  6. Could the channel expose data or allow an unauthorized state change?
  7. Are the same security controls enforced across every channel?

1. REST APIs

1.1 Concept and Structure

REST (Representational State Transfer) is an architectural style for designing HTTP interfaces around resources such as users, orders, and invoices. Here is a fictional example:

GET /api/v1/users/42 HTTP/1.1
Host: app.example.test
Accept: application/json
Authorization: Bearer <ACCESS_TOKEN>
HTTP/1.1 200 OK
Content-Type: application/json

{"id":42,"name":"Test User","email":"user@example.test"}

Core components:

  • Endpoint: A resource path, such as /api/v1/orders/42.
  • HTTP Method: GET is commonly used for reading, POST for creation or actions, PUT for replacement, PATCH for partial updates, and DELETE for deletion.
  • Headers: Metadata such as Authorization and Content-Type.
  • Query Parameters: For example, ?page=2&limit=20.
  • Request Body: Submitted data, commonly JSON.
  • Status Code: Such as 200, 201, 400, 401, 403, 404, 429, or 500.

Do not rely on the method name alone. Some applications use POST for most operations, and an endpoint that appears read-only may still change application state.

1.2 Request Lifecycle

  1. The client sends an HTTP request.
  2. A reverse proxy or API gateway receives it.
  3. Middleware runs, such as session validation and rate limiting.
  4. The router selects a handler.
  5. The service layer checks business rules and permissions.
  6. Data is read or modified.
  7. The result is serialized into a response, commonly JSON.

Security principle: Hiding a button in the frontend is not authorization. The backend must enforce access controls independently.

1.3 Authentication

Authentication answers "Who are you?" It does not, by itself, answer what you are allowed to do.

Common mechanisms:

  • Session Cookie: The browser sends a session identifier that the server validates.
  • Bearer Token: The client sends Authorization: Bearer ....
  • OAuth 2.0 / OpenID Connect: Frameworks used for authorization and identity, depending on the implementation.
  • API Key: Often used for integrations. It is not always a strong user identity mechanism; do not place a long-lived secret in public frontend JavaScript.

Authorized test ideas:

  • Send a request to a protected endpoint without credentials.
  • Use an expired session or invalid token in a test account.
  • Check whether an old session remains usable after logout or a password change.
  • Verify session identifier rotation after login.
  • Look for secrets in URLs, logs, or error messages.

Do not assume every endpoint must require authentication; some resources are intentionally public.

1.4 Authorization and BOLA/IDOR

Authorization answers "Is this identity allowed to perform this action on this resource?"

BOLA (Broken Object Level Authorization) occurs when an application fails to verify access rights to a specific object. IDOR is often used when changing a resource reference allows access to another object.

Safe methodology:

  1. Create two test accounts, A and B, that you control.
  2. Create a test resource for each account.
  3. Capture a request from account A in Burp Suite.
  4. Replace the resource identifier with the identifier of account B's test resource.
  5. Where permitted, repeat for read, update, and delete operations.
  6. Record the response and any state change, with sensitive data redacted.

Also test BFLA (Broken Function Level Authorization): can a regular user invoke an administrative function? Changing IDs alone does not cover this class of issue.

1.5 Serialization and Deserialization

Serialization converts data into a transferable representation, such as JSON. Deserialization converts it back into a data structure the application can use.

Example:

{"displayName":"Test User","timezone":"Africa/Cairo"}

Common risks include:

  • Accepting unexpected data types or values.
  • Relying only on frontend validation.
  • Mass Assignment: Automatically binding request fields to sensitive internal objects.
  • Returning internal fields the client does not need.
  • Unsafe handling of complex objects or types.

To test for Mass Assignment in a test account, first understand the fields the client is allowed to submit. Then add a field not exposed in the UI, such as role, using a harmless test value. Check whether the server rejects or ignores it. Do not attempt to elevate a real account or change data outside the authorized scope.

Mitigations include field allowlists, clear schemas or DTOs, strict type/value validation, and avoiding direct binding of request bodies to database objects.

1.6 Input Validation and Rate Limiting

Check required fields, data types, lengths, empty values, duplicate fields, Content-Type handling, and error messages. Production errors should not reveal stack traces, SQL details, or internal file paths.

Test conservatively: — Limits on login and password-reset attempts. - Repeated sensitive or costly operations. — Pagination and result-size limits. — Whether limits are applied to identities and sessions, not just IP addresses where appropriate. — Idempotency for operations that must not be repeated.

Do not perform load or stress testing without explicit authorization.

1.7 Burp Suite Workflow

  1. Browse the application normally with a test account.
  2. Review Proxy → HTTP history and look for /api/ requests.
  3. Send important requests to Repeater.
  4. Build a matrix of endpoint × method × role × owner.
  5. Test authentication and then authorization using your test accounts.
  6. Compare response bodies and state before and after the request — -not just status codes.
  7. Redact tokens and personal data from evidence.

1.8 REST API Request Flow

None

2. GraphQL

2.1 Concept

GraphQL is a query language and API specification. Many applications expose an endpoint such as /graphql, where the client requests specific fields defined by the schema.

query GetProfile {
  me {
    id
    displayName
    orders {
      id
      status
    }
  }
}

Key terms:

  • Schema: Defines available types, fields, and operations.
  • Query: Reads data.
  • Mutation: Changes state, such as updating a profile.
  • Subscription: Receives ongoing updates and often uses WebSocket as its transport.
  • Resolver: A function that retrieves or computes a field or operation.
  • Introspection: The standard mechanism for querying the GraphQL schema.

GraphQL is not necessarily a transport protocol. It commonly runs over HTTP and may use WebSocket for subscriptions.

2.2 Execution Lifecycle

  1. The GraphQL endpoint receives a request.
  2. Parsing checks the query syntax.
  3. Validation checks the query against the schema.
  4. Resolvers execute for the requested fields.
  5. The response returns data and may also include errors.

An HTTP response may be successful at the transport level while the JSON contains GraphQL errors. Do not rely on the status code alone.

2.3 Authentication and Authorization

GraphQL may use session cookies or Bearer tokens. Subscriptions over WebSocket may require separate connection initialization or authentication.

Test: — Protected queries without login. — Expired or invalid tokens. - Whether subscriptions remain usable after logout. — Whether each sensitive operation is authorized, rather than checking access only when a connection is opened.

Authorization can fail at several levels:

  • Object-level: Can account A read an object belonging to B?
  • Field-level: Can a user read a sensitive field?
  • Nested resolver: Are permissions preserved across user → orders → invoice?
  • Mutation: Can the user modify an object they do not own?
  • Role-based: Can a regular user access administrative operations?

Illustrative query for testing accounts you control:

query {
  user(id: "TEST_USER_ID") {
    id
    displayName
    billingEmail
  }
}

The query itself is not a vulnerability. Test only authorized test data and verify the application's intended access rules.

2.4 Schema Discovery and Introspection

Look for /graphql in captured traffic and authorized documentation. If introspection is available, use it to understand types, fields, and relationships. Introspection alone does not prove a vulnerability; assess whether it exposes unexpected sensitive information or enables unauthorized access.

Applications may use persisted queries or different operation names, so do not assume every GraphQL API is exposed in the same way.

2.5 Query Depth, Complexity, and Batching

Nested queries can become expensive. Review: — Depth limits: Maximum nesting depth. — Complexity/cost limits: Query cost controls. - Pagination: Maximum item counts. — Batching: Many operations in one request. — Timeouts: Execution deadlines. — N+1 queries: One API query triggering many database queries.

Start with small queries and increase complexity gradually. Stop if unexpected latency appears. Do not use queries designed to take the service down.

2.6 Error Leakage and Burp Workflow

Search for /graphql or JSON requests containing query and operationName. Send requests to Repeater, understand the operations and fields, and test Queries and Mutations separately. Compare two test accounts, examine nested fields and permissions, and cautiously assess cost controls. Review errors for stack traces, internal service names, or sensitive data.

2.7 GraphQL Request Execution

None

3. WebSocket

3.1 Concept and Connection Lifecycle

WebSocket is a persistent, bidirectional communication protocol. It commonly begins with an HTTP Upgrade handshake, after which the client and server exchange frames. wss:// uses TLS; ws:// does not.

Common use cases include chat, real-time notifications, games, live dashboards, and GraphQL subscriptions.

Lifecycle: 1. The client sends a handshake request. 2. The server accepts the protocol upgrade. 3. Both sides exchange messages. 4. Either side closes the connection or it disconnects.

Messages may be JSON or binary. Inspect the application rather than assuming a format.

3.2 Authentication and Origin

Authentication may rely on a cookie during the handshake, a token in an initialization message, or a short-lived ticket. Design risks include: - Authenticating the connection but not checking each sensitive message. - Long-lived tokens or tokens in URLs. — Failing to close or revalidate connections after logout or session expiry. — Accepting untrusted Origins in cookie-authenticated browser applications.

Origin validation matters for browser-based applications, but it is not a substitute for authentication or authorization. Non-browser clients may be able to spoof an Origin header.

3.3 Authorization for Every Message

Example fictional message:

{"type":"subscribe","channel":"order-updates","orderId":"TEST_ORDER_ID"}

Within an authorized scope, test: — Can a user subscribe to a channel belonging to another account? — Does the server verify ownership of orderId? - Are permissions checked for every state-changing command? - Are messages still accepted after session expiry? - Does the server reject undocumented message types sent by a test account?

These tests may reveal BOLA/IDOR or BFLA issues.

3.4 Serialization, Validation, and Resource Limits

If messages use JSON, verify: — type is restricted to an allowlist. - Required fields and data types are checked. - Message size and frequency are limited. - Malformed messages are rejected safely. - The user is authorized to send messages to a room or channel. - Content is safely encoded before being rendered as HTML.

JSON serialization does not prevent XSS if data is later inserted into the DOM without safe encoding.

Persistent connections also create risks from excessive connections, repeated messages, expensive subscriptions, and missing idle timeouts. Test at low rates; do not perform DoS testing without explicit permission.

3.5 Burp Suite Workflow

Open Proxy → WebSockets history after using a real-time application feature. Review the handshake and incoming/outgoing messages. Understand message types, IDs, and channels. Use two test accounts to verify data isolation, and test session expiry. Document the messages, responses, and demonstrated impact.

3.6 WebSocket Connection and Security

None

4. Server-Sent Events (SSE)

4.1 Concept

SSE streams events from a server to a client over HTTP. Browsers commonly use the EventSource interface. The primary data flow is Server → Client; client commands are usually sent through separate HTTP requests.

Use cases include live notifications, long-running task progress, file-processing status, and event streams.

Example response:

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache

Example stream content:

event: status
id: 17
data: {"jobId":"TEST_JOB","state":"processing"}

The server may also use retry and id, and the browser may reconnect automatically after a disconnect.

4.2 Authentication and Authorization

SSE may rely on cookies or a custom authentication mechanism. The traditional browser EventSource API does not make arbitrary request headers easy to set in every environment, so implementations differ. Avoid placing long-lived tokens in URLs.

Test: — Access without a session when the stream should be private. - Whether the stream remains active after session expiry. — Whether automatic reconnection reuses stale credentials. — Whether an account can access a job or stream belonging to another account. — Whether authorization applies to later events, not just stream creation. - Whether Last-Event-ID can replay old events without permission checks.

Use only test accounts and resources you control or are explicitly authorized to test.

4.3 Serialization and Output Handling

SSE is a text format and may carry JSON in data: lines. Inspect newline handling, data types, and event sizes. If the client renders data through innerHTML, DOM XSS may be possible depending on context; safe DOM APIs and context-appropriate encoding are preferable.

Long-lived streams need connection limits, idle timeouts, cleanup of disconnected clients, and event-size/rate limits. Do not create many connections to stress the service.

4.4 Burp Suite Workflow

Open the live-update feature, then search HTTP history for text/event-stream or a long-running request. Review the URL, headers, authentication, and event IDs. Compare streams across two test accounts. Where applicable, test reconnection and Last-Event-ID, and check for sensitive data.

4.5 SSE Event Streaming

None

5. gRPC

5.1 Concept

gRPC is a Remote Procedure Call (RPC) framework that lets a client invoke a method on another service over a network. It commonly uses: - Protocol Buffers (Protobuf) to define messages and services. - HTTP/2 as the transport for traditional gRPC. — .proto files to define methods and message types. - Generated client and server code.

Educational example:

syntax = "proto3";

service ProfileService {
  rpc GetProfile (GetProfileRequest) returns (ProfileResponse);
}

message GetProfileRequest {
  string user_id = 1;
}

message ProfileResponse {
  string user_id = 1;
  string display_name = 2;
}

### 5.2 RPC Types

- **Unary:** One request and one response.
- **Server streaming:** One request and multiple server responses.
- **Client streaming:** Multiple client messages followed by a
 response.
- **Bidirectional streaming:** Messages flow in both directions.

**gRPC-Web** allows browser clients to communicate with gRPC services
 through web-compatible mechanisms, often involving a proxy. Do not
 assume every web application calls traditional gRPC directly from the
 browser. A browser may use REST/GraphQL while backend services use gRPC
 internally.

### 5.3 Protobuf Serialization

Protobuf serializes messages into a binary representation. The `.proto`
 file defines field types and field numbers. Binary data is not
 encryption; TLS protects data in transit. Difficulty reading a message
 does not make the API secure.

Potential risks: — Outdated or incompatible schemas. — Values outside
 expected bounds. — Incorrect handling of optional/default fields. -
 Exposure of internal fields. — Assuming a binary format prevents
 unauthorized access.

### 5.4 Authentication and Authorization

gRPC may use metadata to carry an access token, TLS/mTLS for service
 identity, or an intermediary gateway. **mTLS** can authenticate both
 ends of a connection when correctly configured, but it does not replace
 authorization for users and resources.

Test: — Protected RPCs without credentials. — Expired or invalid
 tokens. — Identity checks on every RPC. — Unexpected differences between
 unary and streaming calls. — Whether streams are closed or reauthorized
 when a session expires. — Whether sensitive metadata is logged.

Test two authorization layers: 1. **Method-level:** Is the user allowed
 to call `DeleteAccount` or `GetAdminReport`? 2. **Resource-level:** Is
 the user allowed to access the specified `user_id` or `invoice_id`?

Use test accounts and methods within the authorized scope.

### 5.5 Validation and Resource Controls

Review message-size limits, data types, timeouts, streaming message
 counts, disconnect handling, expensive operations, and leakage through
 status details or logs. Do not intentionally send oversized messages or
 conduct load testing without explicit permission.

### 5.6 Discovering and Testing gRPC

Clues may include `Content-Type: application/grpc` or
 `application/grpc+proto`, HTTP/2 traffic, `.proto` files, or gRPC-Web.
 Depending on the environment and authorization, useful tools include:

- **Burp Suite:** Useful for HTTP traffic and gRPC-Web where
 supported; do not assume binary gRPC messages will be editable as
 plain text.
- **grpcurl:** A CLI client for calling gRPC services when access and
 suitable definitions are available.
- **grpcui:** A web UI for exploring services in a lab or test
 environment.
- **Protobuf tooling:** For understanding message definitions.

Workflow: identify gRPC versus gRPC-Web; obtain `.proto` files or
 reflection metadata from an authorized source; identify RPC methods;
 begin with non-sensitive read operations; test authentication and
 authorization for methods and resources; test boundaries gradually;
 document evidence with secrets redacted.

### 5.7 gRPC Communication Architecture

<picture>
  <source media="(max-width: 768px)" srcset="/img/medium/700/1*gCpxYz31uTFmE8RKxE9yRA.png 1x">
  <source media="(min-width: 769px)" srcset="/img/medium/2000/1*gCpxYz31uTFmE8RKxE9yRA.png 1x">
  <img src="/img/medium/700/1*gCpxYz31uTFmE8RKxE9yRA.png" alt="None" width="1672" height="941" loading="lazy" data-zoom-src="/img/medium/4000/1*gCpxYz31uTFmE8RKxE9yRA.png" class="prose-image"/>
</picture>

### 6. Security Controls Shared by All Five Technologies

### 6.1 Authentication vs. Authorization

#### Concept Question Example:

Authentication Who are you? Validating a session or
 token

Authorization What may you do? Checking permission to
 update an order

Auditing What happened? Safely recording an
 action and its outcome

Successful authentication does not imply successful authorization.
 Verify permissions for every sensitive operation and resource.

### 6.2 Sessions, Cookies, and Tokens

- A **Cookie** is browser-carried data and may contain a session ID.
- A **Session** represents state associated with a user.
- An **Access Token** is a credential validated according to the
 system's design.
- **OAuth 2.0** is an authorization framework; **OpenID Connect** adds
 an identity layer.

Guidance: use HTTPS; configure `Secure`, `HttpOnly`, and `SameSite` for
 cookies as appropriate; use CSRF protection when relying on cookies;
 keep token lifetimes limited and plan revocation/rotation; avoid
 long-lived secrets in public JavaScript or URLs; never log authorization
 headers.

### 6.3 Serialization Is Not Encryption

JSON and Protobuf are representation formats, not encryption. TLS
 protects data in transit, but cannot prevent leakage through logs,
 endpoints, or incorrect access controls. Ask whether schemas exist,
 types and sizes are validated, unexpected fields are accepted, internal
 data is returned, or data is later rendered into HTML/DOM.

### 6.4 Input Validation and Output Encoding

Validate types, lengths, ranges, and allowed values on the server. Use
 allowlists and parameterized queries, and encode output for its context:
 HTML, JavaScript, URL, or DOM. `Content-Type: application/json` does not
 guarantee data is safe when inserted into a UI.

### 6.5 Rate Limiting and Resource Consumption

Controls may be needed for: — Request counts and authentication
 attempts. — Message and connection counts. — Body/frame size. — GraphQL
 depth, complexity, and batching. — Pagination. — Connection or stream
 duration. — Costly business operations.

Test conservatively and only within the authorized scope. Any test that
 may affect availability requires explicit permission and agreed limits.

### 6.6 CORS, CSRF, and Origin

- **CORS** controls how web pages read cross-origin responses; it is
 not a substitute for authorization.
- **CSRF** involves causing a user's browser to send a request using
 their credentials, especially cookies.
- **Origin validation** matters for some browser flows but does not
 prove the identity of every client.
- A CORS header or `OPTIONS` response is not a vulnerability by
 itself; demonstrate a real security impact.

### 6.7 Logging and Error Handling

Ensure that stack traces, tokens, and personal data are not leaked. Log
 denied access attempts safely, distinguish user errors from internal
 failures, and use request/correlation IDs without embedding secrets.

### 7. Bug Bounty Testing Matrix

Use this matrix as a practical checklist when assessing the communication channels used by a web application. Test only assets and functionality covered by your authorization.

### 7.1 REST API

- **Discovery:** Identify endpoints, HTTP methods, parameters, and resources.
- **Authentication:** Test session handling, token validity, expiration, and logout.
- **Authorization:** Check object-level access (BOLA/IDOR) and function-level permissions (BFLA).
- **Serialization:** Review JSON request and response fields, including unexpected or sensitive fields.
- **Input Validation:** Check data types, required fields, boundaries, and unexpected parameters.
- **Resource Controls:** Review rate limits, pagination limits, and restrictions on sensitive operations.
- **Error Handling:** Check for stack traces, internal details, or sensitive information in errors.
- **Session Expiration:** Verify that expired or revoked credentials no longer authorize protected requests.
- **Data Exposure:** Confirm that responses contain only information the current user is allowed to access.

### 7.2 GraphQL

- **Discovery:** Identify the GraphQL endpoint, queries, mutations, schema, and available operations.
- **Authentication:** Test access to protected operations with missing, invalid, or expired credentials.
- **Authorization:** Check object-level, field-level, nested-resolver, and mutation permissions.
- **Serialization:** Review query variables, JSON inputs, and returned fields.
- **Input Validation:** Test argument types, allowed values, and invalid variables.
- **Resource Controls:** Review query depth, complexity limits, batching, pagination, and execution timeouts.
- **Error Handling:** Check GraphQL errors and extensions for unintended information disclosure.
- **Session Expiration:** Verify authorization after logout or credential expiration, including subscriptions where applicable.
- **Data Exposure:** Check whether queries return fields or nested objects that the current user should not access.

### 7.3 WebSocket

- **Discovery:** Identify the handshake, message types, channels, and subscription mechanisms.
- **Authentication:** Check connection authentication and the handling of expired credentials.
- **Authorization:** Verify permissions for individual messages, channels, subscriptions, and referenced resources.
- **Serialization:** Inspect JSON or binary message formats and expected fields.
- **Input Validation:** Test malformed messages, unexpected message types, and invalid field values.
- **Resource Controls:** Review connection limits, message-size restrictions, and message-rate limits.
- **Error Handling:** Inspect error messages and connection-close behavior for unintended information disclosure.
- **Session Expiration:** Check whether an established connection remains authorized after logout or session expiry.
- **Data Exposure:** Verify that broadcasts and channel messages do not expose another user's data.

### 7.4 Server-Sent Events (SSE)

- **Discovery:** Identify endpoints returning `Content-Type: text/event-stream`.
- **Authentication:** Check whether protected streams require valid credentials.
- **Authorization:** Verify access to each resource or job represented in the event stream.
- **Serialization:** Inspect event IDs, event types, and data payloads.
- **Input Validation:** Review parameters used to select streams or resources.
- **Resource Controls:** Check connection limits, event-size limits, and stream timeouts.
- **Error Handling:** Review error events and server responses for unintended disclosures.
- **Session Expiration:** Check behavior after logout, credential expiry, and automatic reconnection.
- **Data Exposure:** Verify that event payloads and replayed events do not reveal unauthorized information.

### 7.5 gRPC

- **Discovery:** Identify services, RPC methods, message definitions, and whether the application uses gRPC or gRPC-Web.
- **Authentication:** Test credentials and metadata on protected RPCs and streaming calls.
- **Authorization:** Check method-level and resource-level permissions.
- **Serialization:** Review Protobuf message schemas, field types, and unexpected values.
- **Input Validation:** Test invalid field values, missing required application data, and boundary conditions.
- **Resource Controls:** Review message-size limits, streaming limits, timeouts, and operation costs.
- **Error Handling:** Check status details and logs for internal information disclosure.
- **Session Expiration:** Verify behavior for long-lived streams and expired or revoked credentials.
- **Data Exposure:** Ensure responses contain only fields the caller is authorized to access.

### How to Use This Matrix

1. Map the communication channels actually used by the application.
2. Capture normal traffic before modifying requests.
3. Test authentication separately from authorization.
4. Use test accounts you control to verify access boundaries.
5. Validate any suspected issue with the smallest safe test.
6. Document reproducible evidence and demonstrated impact.

**Important:** The presence of an endpoint, schema, protocol, or error message does not by itself establish a vulnerability. Findings should demonstrate a security control failure and its actual impact.

### 7.6 Checklist

- Read the program scope and restrictions.
- Prepare two test accounts you control, where needed.
- Document expected roles and permissions.
- Identify the communication channels actually used.
- Capture normal requests before modifying them.
- Test authentication separately from authorization.
- Test access to other authorized test resources.
- Review extra fields and returned data.
- Test usage limits conservatively.
- Redact secrets and personal data from evidence.
- Stop if an unexpected result could harm the service or expose
 real users' data.

### 7.7 Recommended Testing Order

1. **Map the attack surface:** Understand the application's features
 and channels.
2. **Capture baseline traffic:** Record normal requests.
3. **Build an authorization matrix:** Map roles to operations and
 resources.
4. **Test authentication:** Sessions, tokens, expiry, and logout.
5. **Test authorization:** BOLA/IDOR, BFLA, field-level and
 message-level permissions.
6. **Test data handling:** Validation, serialization, and output
 encoding.
7. **Test resource controls:** Use conservative tests.
8. **Validate impact:** Prove the issue with the smallest possible
 change.
9. **Document and report:** Provide reproducible steps, clear impact,
 and remediation.

### 8. Professional Vulnerability Report Template

### Title

A concise title, such as
 `BOLA in Order Details API Allows Cross-Account Access`.

### Summary

Explain the expected behavior and what actually happened.

### Affected Asset

The affected endpoint/RPC/stream, environment, and test role.

### Preconditions

Requirements to reproduce the issue, without real passwords or tokens.

### Steps to Reproduce

1. Log in as test account A.
2. Create or open a test resource you own.
3. Capture the original request.
4. Make the specific change.
5. Show the response and impact.

### Expected vs. Actual

- **Expected:** Behavior required by the application's rules and
 permissions.
- **Actual:** What occurred during the test.

### Impact

Describe demonstrated, realistic impact without exaggeration.

### Evidence

Redacted requests/responses and screenshots where useful.

### Remediation

Enforce authorization on every resource and operation; use schemas and
 allowlists; restrict modifiable fields; set resource limits; terminate
 or revalidate connections on session expiry; add regression tests.

### What Does Not Prove a Vulnerability by Itself?

- The existence of `/api/`, `/graphql`, or a WebSocket endpoint.
- Being able to read the GraphQL schema.
- The use of HTTP/2 or Protobuf.
- A different status code without security impact.
- A generic error message.
- A CORS header without an exploit scenario.
- Being able to connect to WebSocket/SSE without unauthorized access.

A strong report connects the root cause to reproducible steps and actual
 security impact.

### 9. Review Questions

1. What is the difference between authentication and authorization?
2. Why is GraphQL not necessarily a transport protocol?
3. How do WebSocket and SSE differ in communication direction?
4. Why must every sensitive WebSocket message be authorized?
5. What is BOLA, and how can you test it with two test accounts?
6. What is the difference between JSON serialization and TLS
 encryption?
7. Why is an HTTP status code insufficient to assess a GraphQL result?
8. What is the difference between gRPC and gRPC-Web?
9. What risks can arise from replaying SSE events through
 `Last-Event-ID`?
10. How can you prove impact without accessing real users' data?
11. Why is hiding an administrative UI button insufficient?
12. How can you reduce the cost of GraphQL queries and streaming
 messages?

### 10. Conclusion

The goal is not simply to memorize five technologies. It is to
 understand how data moves, how identity is established, where
 permissions are enforced, how inputs are validated, and how resources
 are constrained.

- **REST:** Understand endpoints, methods, and resources.
- **GraphQL:** Understand schemas, resolvers, and field/operation
 permissions.
- **WebSocket:** Treat persistent connections as requiring
 authorization at message level.
- **SSE:** Treat event streams as long-lived channels that may persist
 or replay events after session changes.
- **gRPC:** Understand typed/binary RPC messages; difficulty reading a
 message does not mean the interface is secure.

For bug bounty work, start by browsing the application normally,
 capturing traffic, and building a clear matrix of roles and resources.
 Test each channel separately with accounts you control. Focus on proving
 access-control, business-logic, or data-protection failures — -not merely
 the presence of a technology.