API Feedback Endpoint Security Test Plan

This document outlines a comprehensive security test plan for the `/api/v1/web/feedback` endpoint on `testfrontend.nobrokerage.com`, leveraging Burp Suite for detailed analysis and exploitation. It covers various vulnerability categories, annotated request details, and a step-by-step workflow for effective penetration testing.

This document is for authorized security testing only. Only perform these tests on systems you own or have explicit written authorization to test. Unauthorized testing is illegal under the Computer Fraud and Abuse Act (CFAA), India's IT Act, and equivalent laws in other jurisdictions.

1. Vulnerability Summary

This section summarizes potential vulnerabilities identified for the `/api/v1/web/feedback` endpoint. High-severity issues include Session validation bypass, IDOR via anonymous_id, Metadata IP spoofing, Metadata country bypass, Injection in Metadata fields, CORS misconfiguration, CSRF - missing token check, SSRF via pageUrl, and Stored XSS in comment. Medium and Low severity issues are also listed, all currently marked as 'Pending' for testing.

2. Annotated Request

The original request with security-relevant areas noted below:

The base request for testing is a `POST` to `/api/v1/web/feedback` on `testfrontend.nobrokerage.com`. Critical areas for security testing include the `Cookie` header (specifically `anonymous_id` and `sessionId`), the `Referer` and `Origin` headers for CSRF and CORS, the custom `Metadata` header (which contains client-supplied IP and geolocation data), and the JSON body fields (`rating`, `comment`, `pageUrl`, `category`) as potential injection surfaces.

Key markers for testing include: `[CRITICAL] Cookie` (High risk for session validation, IDOR, fixation), `[CRITICAL] Metadata` (High risk, server must not trust client-supplied IP/geo), `[CSRF] Referer` (High risk, remove to test CSRF), `[CORS] Origin` (High risk, change to `evil.com` to test CORS), and `[INJECTION] Body` (High risk, all four fields are injectable for XSS, SQLi, SSRF).

3. Session & Authentication Testing

3.1 Session Validation Bypass

This test verifies if the server validates the `sessionId` cookie, expecting a 401 or 403 response for invalid or missing sessions. Payloads include removing the cookie, using an empty session ID, an invalid session ID, or a random UUID. A 200 OK response indicates a server-side authentication bypass.

3.2 IDOR via anonymous_id

This test checks for Insecure Direct Object Reference (IDOR) by replacing the `anonymous_id` with different UUIDs (e.g., a swapped ID, sequential ID, or zero UUID). The goal is to see if the response reveals data from another user or if feedback is stored under the swapped ID. Burp Comparer is recommended to diff responses.

3.3 Session Fixation

This test involves sending a self-crafted `sessionId` value. If the server accepts it and associates feedback with this ID, it indicates a session fixation vulnerability, allowing an attacker to fix a victim's session.

3.4 Cookie Flag Inspection

Using browser developer tools or Burp Proxy, verify that the `sessionId` cookie has `HttpOnly`, `Secure`, and `SameSite=Strict` or `Lax` flags set. Missing any of these flags is a security finding.

4. Metadata Header Testing

CRITICAL FINDING: The Metadata header is a custom, client-supplied header containing IP and geolocation data. The server must never trust client-supplied IP information. This is a design vulnerability before any testing begins.

4.1 IP Spoofing via Metadata

This test involves changing the `ip` field within the `Metadata` header to values like `localhost`, private IP ranges, or cloud metadata IPs (e.g., `169.254.169.254`). Success in bypassing rate-limiting, access control, or logging mechanisms indicates a vulnerability.

4.2 Geo / Country Bypass

This test changes the `country` field in the `Metadata` header (e.g., to 'US' or 'GB') to bypass region-based restrictions, different rate limits, or country-specific features.

4.3 Injection in Metadata Fields

This test injects SQLi and XSS payloads into `city`, `org`, `hostname`, and `postal` fields within the `Metadata` header. These fields are often logged or stored, potentially leading to XSS in admin dashboards or SQL injection.

4.4 Remove Metadata Header

This test involves deleting the entire `Metadata` header. Outcomes to observe are server errors (5xx/400), indicating the header is used in logic and trusted, or a 200 OK, suggesting it's decorative or optional. This helps confirm server reliance on client-supplied geo data.

5. JSON Body Injection Testing

5.1 Stored XSS in comment Field

This test injects various XSS payloads (e.g., ``, `

`, `

5.2 SSRF via pageUrl Field

This test checks for Server-Side Request Forgery (SSRF) by injecting internal or external URLs into the `pageUrl` field. Payloads include AWS metadata IPs, `localhost` admin pages, internal network IPs, `file:///etc/passwd`, and Burp Collaborator URLs. Detection via Burp Collaborator confirms SSRF.

5.3 SQL Injection

This test targets the `category` and `comment` fields for SQL injection using payloads like `' OR '1'='1`, `'; DROP TABLE feedback;--`, and time-based blind SQLi (`' AND SLEEP(5)--`). Burp Intruder/Scanner is recommended, with a focus on response times for blind injections.

5.4 Type Confusion & Boundary Tests

This test sends unexpected data types and boundary values for fields like `rating` (e.g., negative, huge, float, null, string) and other fields (null, boolean, array, object). Poor backend validation might cause panics, stack traces, or silent acceptance of invalid data. The `__proto__` payload specifically tests for prototype pollution in Node.js applications.

5.5 Oversized Payload (DoS)

This test sends an oversized `comment` field (e.g., 100,000+ characters) to check for Denial of Service (DoS) vulnerabilities. The server should ideally reject it with a 413 status code; processing or storing it indicates a potential DoS.

6. Header, CORS & CSRF Testing

6.1 CORS Misconfiguration

This test checks for Cross-Origin Resource Sharing (CORS) misconfigurations by sending requests with various `Origin` headers (e.g., `https://evil.com`, `null`, subdomain spoofing, HTTP downgrade). A critical finding occurs if the server reflects an arbitrary `Origin` in `Access-Control-Allow-Origin` combined with `Access-Control-Allow-Credentials: true`.

6.2 CSRF Testing

This test checks for Cross-Site Request Forgery (CSRF) by removing `Origin` and `Referer` headers or using a wrong `Referer`. A 200 OK response when these headers are missing indicates a CSRF vulnerability, especially if no CSRF token is present in the request body. A 403 Forbidden is the expected secure response.

6.3 HTTP Downgrade

This test sends the request over plain HTTP. The server should either redirect to HTTPS (301) or reject the request. The absence of the `Strict-Transport-Security` header in the response indicates HSTS is not configured.

6.4 Content-Type Bypass

This test changes the `Content-Type` header (e.g., `text/plain`, `application/x-www-form-urlencoded`, `multipart/form-data`, or removed entirely). Some middleware might only validate JSON when `Content-Type` is `application/json`, allowing a bypass of input validation.

7. Rate Limiting & DoS Testing

7.1 Baseline Rate Limit Test

This test sends 500 identical requests using Burp Intruder with Null payloads to check for rate limiting. A properly configured server should return 429 Too Many Requests after a threshold. If all 500 requests return 200 OK, rate limiting is absent.

7.2 Rate Limit Bypass via Metadata.ip Rotation

This test attempts to bypass rate limiting by rotating the `ip` value within the `Metadata` header for each request. If rate limiting relies on this client-supplied IP instead of the real TCP source IP, this bypass confirms a vulnerability stemming from trusting client data.

7.3 Duplicate Submission

This test sends the exact same request 10 times rapidly to check for deduplication mechanisms. It verifies if the server returns the same response ID, creates multiple entries, or errors after a certain number of submissions from the same session.

8. Burp Suite Step-by-Step Workflow

Step 1 — Capture & Import

Instructions for capturing the initial request in Burp Proxy and sending it to Repeater, Intruder, and Scanner for further testing.

Step 2 — Repeater (Manual Tests)

Guidance on using Burp Repeater for individual payload tests, emphasizing making one change at a time, observing responses, and using Comparer for diffing.

Step 3 — Burp Collaborator (SSRF Detection)

Detailed steps for using Burp Collaborator to detect out-of-band interactions for SSRF testing, including copying the unique Collaborator subdomain and polling for DNS/HTTP hits. An example payload is provided: `{"rating":4,"comment":"ssrf-test","pageUrl":"http://abc123.burpcollaborator.net","category":"General"}`.

Step 4 — Intruder (Automated Fuzzing)

Instructions for configuring Burp Intruder for automated fuzzing, including setting payload positions, attack types (Sniper, Cluster Bomb), payload types (Simple list, Numbers, Null payloads), and loading SecLists wordlists for XSS, SQLi, and SSRF. Recommended SecLists payload paths are: `/Fuzzing/XSS/XSS-Jhaddix.txt`, `/Fuzzing/SQLi/Generic-SQLi.txt`, `/Fuzzing/SSRF.txt`, and `/Discovery/Web-Content/burp-parameter-names.txt`.

Step 5 — Active Scanner (Pro)

Guidance on using Burp Suite Professional's Active Scanner to automatically test for common vulnerabilities like SQL injection, XSS, path traversal, and header injection, with a recommendation to prioritize High confidence findings.

Step 6 — Response Headers to Check

A list of critical security response headers to inspect after every test, including `Strict-Transport-Security` (risk if missing: HTTP downgrade possible), `Content-Security-Policy` (risk if missing: XSS escalation), `X-Frame-Options` (risk if missing: Clickjacking), `X-Content-Type-Options` (risk if missing: MIME sniffing), `Access-Control-Allow-Origin` (risk if missing: CORS data theft), and `Set-Cookie` flags (`HttpOnly; Secure; SameSite=Strict` - risk if missing: Session hijack / CSRF).

9. Testing Checklist

A comprehensive checklist of 27 tests covering session, metadata, JSON body, header, CORS, CSRF, and rate limiting vulnerabilities, each with its severity and a 'Done' checkbox for tracking progress. Key tests include removing/invalidating `sessionId` cookies, swapping `anonymous_id` for IDOR, checking cookie flags, IP/geo spoofing via `Metadata`, injecting SQLi/XSS into `Metadata` fields and JSON body (`comment`, `category`), SSRF via `pageUrl`, type confusion, oversized payloads, CORS misconfiguration, CSRF checks, HTTP downgrade, `Content-Type` bypass, and various rate limiting tests.