Security Test Reporting
Security vulnerabilities require specialized reporting - stakeholders need to understand the risk, impact, and urgency differently than functional bugs. A security bug report must convey: what the vulnerability is, how it was discovered, what an attacker could do with it, and a clear CVSS-aligned severity rating. Poor security reporting leads to vulnerabilities being deprioritized.
Security Vulnerability Report Template
// ══════════════════════════════════════════════════════════════
// SECURITY VULNERABILITY REPORT FORMAT
// (Used by professional security testers and bug bounty hunters)
// ══════════════════════════════════════════════════════════════
const securityVulnerabilityReport = {
// Header:
id: "SEC-042",
title: "IDOR: Regular users can read any user's order history via /api/orders/{id}",
reporter: "QA Security Team",
date: "2026-03-30",
status: "Open",
// Severity Classification:
cvssScore: 7.5, // CVSS v3.1 Base Score
severity: "High", // Critical/High/Medium/Low/Informational
owasp: "A01:2021 - Broken Access Control",
// Impact (what can an attacker do with this?):
impact: `
An authenticated user can enumerate other users' complete order history
by incrementing the order ID in the URL path. This exposes:
- Purchase history (products and quantities)
- Delivery addresses
- Partial payment information (last 4 digits)
- Order status and tracking information
Affects approximately 150,000 users with order histories.
`,
// Proof of Concept (exact steps to reproduce):
poc: `
1. Login as alice@test.com (user ID: 123)
2. Create an order (order ID: ORD-1001 assigned)
3. Send: GET /api/orders/ORD-1002 with Alice's Auth token
4. Response: 200 OK with Bob's complete order data
HTTP Request:
GET /api/orders/ORD-1002
Authorization: Bearer eyJhbGc...
HTTP Response:
200 OK
{
"orderId": "ORD-1002",
"userId": 124, ← Different user
"items": [...],
"deliveryAddress": "123 Bob Street, New York...",
"lastFourDigits": "1234"
}
`,
// Evidence:
evidence: [
"screenshot-idor-request-response.png",
"screen-recording-idor-demo.mp4",
"burp-suite-request-log.txt"
],
// Remediation:
remediation: `
Server-side fix required:
1. Add user ownership check before returning order:
if (order.userId !== req.user.id) { return res.status(403).json({error: "Forbidden"}) }
2. Consider opaque order IDs (UUID) instead of sequential integers
Verification:
After fix, GET /api/orders/ORD-1002 as alice should return 403.
`,
// Risk Timeline:
timeline: {
discovered: "2026-03-30",
reported: "2026-03-30",
fixDeadline: "2026-04-06", // 7 days for High severity
fixed: null, // To be filled on resolution
}
};Quick Quiz - Security Testing
Common Mistakes
- Reporting without proof of concept - a security vulnerability without reproduction steps will be deprioritized; always include exact request/response evidence
- Incorrect severity rating - IDOR exposing only usernames is Medium; IDOR exposing financial data is High/Critical; use CVSS scoring for objective ratings
- No remediation suggestion - testers find vulnerabilities; security reports should also suggest the fix direction (not the exact code, but the security control needed)
- Too long time-to-report on critical findings - High and Critical security vulnerabilities should be reported immediately (within 24 hours), not at the end of the sprint
Tip
Tip
Practice Security Test Reporting in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Allure for rich reports.
Practice Task
Note
Practice Task - (1) Write a working example of Security Test Reporting from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Common Mistake
Warning
A common mistake with Security Test Reporting is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready software testing code.
Key Takeaways
- Security vulnerabilities require specialized reporting - stakeholders need to understand the risk, impact, and urgency differently than functional bugs.
- Reporting without proof of concept - a security vulnerability without reproduction steps will be deprioritized; always include exact request/response evidence
- Incorrect severity rating - IDOR exposing only usernames is Medium; IDOR exposing financial data is High/Critical; use CVSS scoring for objective ratings
- No remediation suggestion - testers find vulnerabilities; security reports should also suggest the fix direction (not the exact code, but the security control needed)