This penetration test plan is produced for authorized security assessments only. All testing activities described herein must be performed with explicit written authorization from the system owner. Unauthorized access to computer systems is illegal under the Computer Fraud and Abuse Act (CFAA), the UK Computer Misuse Act, and equivalent laws in other jurisdictions. The author of this plan assumes no liability for misuse.

1. Reconnaissance: Explore the codebase to understand the application's architecture, technology stack, and attack surface
2. Analysis: Identify potential vulnerabilities, weak patterns, and security-relevant configurations
3. Planning: Produce a structured, actionable pentest plan document covering all major attack categories
4. Prioritization: Rank test cases by risk severity and likelihood of exploitation
5. Tooling: Recommend appropriate tools for each testing phase

• package.json

  ,

  requirements.txt

  ,

  Gemfile

  ,

  go.mod

  ,

  pom.xml

  ,

  build.gradle

  ,

  Cargo.toml

  ,

  composer.json

  (dependency manifests)

• Dockerfile

  ,

  docker-compose.yml

  ,

  docker-compose.yaml

  (containerization)

• .env

  ,

  .env.example

  ,

  .env.local

  ,

  .env.production

  (environment configuration -- note secrets found but DO NOT include actual secret values in the plan)

• next.config.js

  ,

  nuxt.config.js

  ,

  vite.config.ts

  ,

  webpack.config.js

  (frontend build configuration)

• nginx.conf

  ,

  apache.conf

  ,

  Caddyfile

  ,

  traefik.yml

  (reverse proxy / web server configuration)

• tsconfig.json

  ,

  babel.config.js

  (language configuration)

• Makefile

  ,

  Procfile

  ,

  fly.toml

  ,

  vercel.json

  ,

  netlify.toml

  ,

  render.yaml

  (deployment configuration)

Glob: **/{package.json,requirements.txt,Gemfile,go.mod,pom.xml,Cargo.toml,composer.json}
Glob: **/{Dockerfile,docker-compose.yml,docker-compose.yaml}
Glob: **/.env*
Glob: **/nginx.conf
Glob: **/vercel.json

DISCLAIMER: This penetration test plan is produced for authorized security assessments only. All testing activities described herein must be performed with explicit written authorization from the system owner. Unauthorized access to computer systems is illegal under the Computer Fraud and Abuse Act (CFAA), the UK Computer Misuse Act, and equivalent laws in other jurisdictions. The author of this plan assumes no liability for misuse.

1. Executive Summary
2. Scope Definition
3. Technology Stack Profile
4. Attack Surface Map
5. OWASP Top 10 Test Cases
6. Authentication Testing
7. Authorization Testing
8. API Security Testing
9. Injection Vector Testing
10. Business Logic Abuse Scenarios
11. Infrastructure and Configuration Testing
12. Client-Side Security Testing
13. Data Protection and Cryptography Testing
14. Dependency and Supply Chain Testing
15. Test Schedule
16. Tools and Environment
17. Expected Deliverables
18. Risk Rating Methodology
19. Rules of Engagement
20. Appendix: Discovered Endpoints

• What the application does (based on codebase analysis)
• The overall security posture observed during reconnaissance
• Key areas of concern identified
• Recommended testing priority]

• Allowed Actions: [Enumerate permitted testing activities]
• Prohibited Actions: [Enumerate actions requiring additional authorization]
  • Denial of service testing
  • Social engineering against employees
  • Physical access testing
  • Testing of third-party services without their authorization
  • Modification or deletion of production data
  • Exfiltration of real user data

• Environment: [Production / Staging / Development -- recommend staging]
• Test Accounts Required: [List roles and account types needed]
• Data Requirements: [Seed data, test payment credentials, etc.]

• Public Zone: [Endpoints accessible without authentication]
• Authenticated Zone: [Endpoints requiring valid session/token]
• Admin Zone: [Endpoints requiring elevated privileges]
• Service-to-Service: [Internal API calls between microservices]

1. [Client] --> [CDN/Reverse Proxy] --> [Application Server] --> [Database]
2. [Client] --> [API Gateway] --> [Microservice A] --> [Message Queue] --> [Microservice B]
3. [etc.]

• Browser to server (all user input)
• Server to database (query construction)
• Server to external APIs (data validation)
• File upload to storage (content validation)
• Webhook receivers (signature verification)

• Missing authorization middleware on routes
• Inconsistent access control patterns
• Direct object references without ownership checks
• Missing CORS restrictions]

• String concatenation in queries
• Unsanitized user input passed to database calls
• Use of eval(), exec(), or similar dangerous functions
• Raw SQL queries without parameterization]

• Session-based vs Token-based (JWT, OAuth)
• Authentication provider (custom, Auth0, Firebase, Cognito, etc.)
• Password storage mechanism
• Multi-factor authentication presence
• Social login integrations
• API key authentication for service-to-service]

• RBAC, ABAC, ACL, or custom
• Role hierarchy
• Resource ownership model
• Multi-tenancy isolation
• Admin vs user boundary]

• REST, GraphQL, gRPC, WebSocket
• API versioning strategy
• Rate limiting implementation
• Request/response formats
• API documentation exposure]

• Form fields
• URL parameters
• HTTP headers
• File uploads
• API request bodies
• WebSocket messages
• Webhook payloads
• Search queries
• Import/export functionality]

• User registration and onboarding
• Payment/billing processes
• Content creation and publishing workflows
• Invitation and sharing mechanisms
• Subscription and plan management
• Reward/loyalty systems
• Referral programs
• Rate-limited or metered features]

• Written authorization is current and covers the phase activities
• Test environment is isolated from production (if applicable)
• Backup/rollback procedure is confirmed with system owner
• Emergency contact information is available
• Monitoring/alerting team is aware of testing window

• Kali Linux or Parrot OS (or macOS/Windows with tools installed)
• Minimum 16GB RAM, SSD storage
• Stable network connection to target
• VPN access if target is internal

• FoxyProxy (proxy switching)
• Wappalyzer (technology detection)
• Cookie Editor
• JWT.io Debugger
• Retire.js (client-side library detection)

• Burp Suite configured as upstream proxy
• Browser certificate installed for TLS interception
• Scope configured to limit testing to authorized targets only
• Logging enabled for all tools to support evidence collection

1. Document Control (version, distribution, classification)
2. Executive Summary
3. Scope and Methodology
4. Risk Summary Dashboard (by severity, by category, by OWASP)
5. Detailed Findings (each finding includes):
   • Unique ID and title
   • Severity (Critical/High/Medium/Low/Informational)
   • CVSS v3.1 score and vector
   • OWASP Top 10 mapping
   • CWE identifier
   • Affected component(s) with file paths
   • Description of the vulnerability
   • Evidence (screenshots, request/response pairs)
   • Steps to reproduce
   • Business impact assessment
   • Remediation recommendation (with code examples where applicable)
   • References (CVE, CWE, external advisories)
6. Positive Findings (security controls working correctly)
7. Appendix A: Tools and Versions Used
8. Appendix B: Full Endpoint Inventory
9. Appendix C: Raw Scanner Output (sanitized)

• Skill level required
• Availability of exploit code
• Attack complexity
• Authentication requirements

• Confidentiality loss (data exposure)
• Integrity loss (data modification)
• Availability loss (service disruption)
• Financial impact
• Regulatory/compliance impact
• Reputational impact

1. Authorization: All testing must be covered by signed authorization. Testing must stop immediately if authorization is revoked.
2. Scope: Only test assets explicitly listed in Section 2. Any out-of-scope asset discovered must be reported, not tested.
3. Data Handling: Never exfiltrate, store, or transmit real user data. Use only test accounts and synthetic data.
4. Communication: Report critical findings immediately. Maintain daily status updates.
5. Evidence: Capture sufficient evidence to reproduce findings. Never alter or destroy evidence.
6. Tools: Only use tools listed in Section 16 unless pre-approved. No custom exploit code without authorization.
7. Social Engineering: No social engineering, phishing, or physical access testing unless explicitly authorized.
8. Denial of Service: No intentional DoS testing unless specifically authorized and target environment is isolated.
9. Cleanup: Remove all test accounts, uploaded files, and artifacts upon completion.
10. Confidentiality: All findings are confidential. Share only with authorized recipients listed in the authorization document.

• Complete technology stack with versions
• Every API route/endpoint with HTTP method and parameters
• Authentication mechanism details
• Authorization model and role definitions
• Database schema and query patterns
• File upload handling
• Third-party integrations
• Security middleware and configurations
• Infrastructure and deployment setup
• Environment variable usage (names only, never values)
• Error handling patterns
• Logging implementation

• OWASP Top 10 (2021)
• OWASP API Security Top 10 (2023)
• CWE Top 25 Most Dangerous Software Weaknesses
• SANS Top 25
• Relevant compliance frameworks (PCI DSS, HIPAA, GDPR, SOC 2)

• Missing security controls
• Inconsistent security patterns (some endpoints protected, others not)
• Known vulnerable dependency versions
• Hardcoded secrets or credentials (report existence, never the values)
• Insecure default configurations
• Business logic that could be abused
• Data flow paths that lack validation

pentest-plan.md

• Reference actual file paths, function names, and line numbers where issues were found
• Include the exact endpoint paths discovered
• Note which security controls ARE present (positive findings)
• Prioritize test cases based on the specific application's risk profile
• Tailor the tools section to the application's technology stack
• Adjust the schedule based on application complexity
• Include application-specific business logic abuse scenarios

• Total number of endpoints discovered
• Number of test cases generated by category
• Top 5 areas of highest concern
• Recommended immediate actions (before the pentest begins)
• Any critical issues discovered during reconnaissance that warrant immediate attention

• Never include actual secret values in the pentest plan. Note their existence and location only.
• Never execute actual attacks. This skill generates plans, not exploits.
• Always include the authorization disclaimer at the top of the generated plan.
• Be specific. Generic pentest plans are useless. Every test case should reference actual code, endpoints, or configurations found in the target application.
• Include positive findings. Note where security is done well. This helps the team understand their existing posture and protects against regression.
• Consider the business context. A vulnerability in a payment endpoint is more critical than the same vulnerability in a public blog comment.
• Output the plan as

  pentest-plan.md

  in the project root directory.
• The plan should be comprehensive enough that a qualified penetration tester could execute the test using only this document and their tools.