Production External Security Testing Directive (Non-Destructive - PostgreSQL, Laravel, Next.js)

1. Objective

Conduct external, non-destructive security testing on a production system to:
	•	Identify externally exposed attack surfaces (API, Web, CDN, Admin interfaces)
	•	Detect data leakage, authorization flaws (IDOR), misconfigured CORS, exposed debug endpoints, cache misconfigurations, weak rate-limiting, and improper access controls
	•	Produce a clear, reproducible security report with remediation guidance

The goal is risk reduction, not exploitation.

⸻

2. Scope

In scope
	•	Public web application
	•	Public API
	•	CDN / static asset delivery
	•	Admin interface (authentication & access control checks only)

Out of scope
	•	Denial of Service, stress testing, or high-traffic scans
	•	Destructive payloads (data deletion, modification, file uploads, RCE)
	•	Credential brute-force or account takeover attempts
	•	Pivoting to third-party systems

⸻

3. Test Accounts
	•	Anonymous (unauthenticated) access
	•	Standard user account (provided by product owner)
	•	Admin access only if explicitly authorized; otherwise limited to surface-level checks (redirects, headers, CSRF protection)

No other accounts may be used.

⸻

4. Operational Safety Rules (Mandatory)
	•	Low-noise execution: 1–2 requests/sec, no burst traffic
	•	Custom User-Agent identifying security test activity
	•	Prefer single IP (or known IP range) and notify beforehand
	•	Continuous monitoring of application logs, API logs, database connections, cache, and queues during testing
	•	All test tokens and sessions must be revoked after completion

⸻

5. Deliverables

5.1 API Inventory
	•	Endpoint list (method, path, authentication requirement, role)
	•	Minimal request/response samples (PII masked)
	•	Clear separation of anonymous vs authenticated endpoints

5.2 Security Findings Report

For each finding:
	•	Title
	•	Severity (Critical / High / Medium / Low)
	•	Affected component
	•	Reproduction steps (safe, non-destructive)
	•	Impact description
	•	Likely root cause
	•	Remediation recommendation

5.3 Fix Backlog
	•	Prioritized list of actionable fixes (short-term / medium-term)

⸻

6. Test Plan

A. Passive Reconnaissance & Configuration Review
	•	TLS and HTTP security headers (HSTS, CSP, X-Frame-Options, etc.)
	•	CORS policy validation (no wildcard + credentials misuse)
	•	Exposure of common misconfig paths (debug, metrics, health, env, backups)
	•	Cache behavior review (authenticated responses must not be cached publicly)

Tools
	•	Nikto (baseline checks only, no aggressive mode)
	•	Nuclei (misconfiguration & exposure templates only; intrusive templates disabled)

⸻

B. API Surface Enumeration
	•	Check for OpenAPI / Swagger exposure
	•	Extract endpoints from frontend (Next.js) and mobile (Flutter) network traffic
	•	Limited path discovery using small wordlists and GET-only requests

Rules:
	•	Enumeration only; no bulk data extraction
	•	Pagination limited to minimal samples

⸻

C. Authorization & Access Control Testing
	•	IDOR checks (resource access by altering identifiers)
	•	Role enforcement validation (user token against privileged endpoints)
	•	Multi-tenant isolation checks (organization / workspace parameters)

Evidence must avoid exposing real user data; masking is mandatory.

⸻

D. Input Validation & Injection (Strictly Controlled)
	•	Validate server-side input handling and error behavior
	•	SQL injection testing only as a signal, not exploitation
	•	Low threads, no time-based or heavy payloads
	•	No schema enumeration, no data dumping

Purpose: confirm presence or absence of injection risk, nothing more.

⸻

E. Authentication & Session Security
	•	Cookie flags (HttpOnly, Secure, SameSite)
	•	Token lifecycle (expiration, rotation)
	•	Rate-limiting on login and sensitive actions
	•	Password reset token entropy and reuse protection

⸻

F. CDN & Static Asset Leakage
	•	Exposure of sensitive files (configs, logs, backups, source maps)
	•	Directory listing checks
	•	Cache headers validation for private content

⸻

7. Tool Usage Principles
	•	ffuf: low-rate, small wordlists, GET requests only
	•	nuclei: safe templates only
	•	nikto: informational checks only
	•	sqlmap: verification-level usage, no data extraction

Any scan that risks service degradation is prohibited.

⸻

8. Reporting Format (Standardized)

Each finding must include:
	•	Title
	•	Severity
	•	Affected asset
	•	Evidence (sanitized)
	•	Impact
	•	Root cause hypothesis
	•	Recommended fix (code/config reference)
	•	Post-fix verification steps

⸻

9. Post-Test Validation Checklist
	•	Debug and verbose errors disabled in production
	•	Authorization policies enforced at server level
	•	Rate limits active on authentication and critical APIs
	•	CORS restricted to approved origins
	•	Authenticated responses marked private / no-store
	•	Admin interface protected against brute-force
	•	CDN blocks sensitive file types
	•	No secrets accessible via public paths
	•	Source maps disabled in production (unless explicitly required)
	•	Security headers consistently applied

⸻

10. Expected Outcome

A clear view of the real external attack surface, validated authorization boundaries, and a prioritized remediation plan — without harming production systems or user data.