Skip to content

Web Application

I. Planning, Reconnaissance & Information Gathering (Pre-Engagement & Pre-Exploitation)

  • A. Scoping & Rules of Engagement
    • Define Target URLs/Applications/APIs
    • Define Testing Scope (e.g., specific functionalities, subdomains, out-of-scope areas)
    • Define Objectives (e.g., identify OWASP Top 10, specific data exfiltration, RCE)
    • Define Allowed/Disallowed Test Types (e.g., DoS/DDoS, aggressive scanning, social engineering of app users)
    • Define Testing Window & Blackout Periods
    • Establish Communication Channels & Escalation Paths
    • Obtain Explicit Written Authorization
    • Identify Test Accounts (roles: unauthenticated, authenticated user, admin, etc.)
    • Discuss Incident Response Plan (client-side) if critical issues are found
    • NDA and Legal Agreements in Place
    • Understand Business Logic and Critical Workflows
  • B. Passive Reconnaissance (OSINT & Non-Intrusive)
    • Identify Hosting Provider & IP Addresses
    • Gather DNS Information (A, CNAME, MX, TXT, SPF, DMARC, DKIM)
    • Subdomain Enumeration (Search engines, DNSDumpster, VirusTotal, Sublist3r, Amass,crt.sh)
    • Identify Related Domains & Acquired Company Applications
    • Search Engine Dorking (Google, Bing, DuckDuckGo) for:
      • Login Pages
      • Admin Portals
      • Error Messages
      • Exposed Files (config, logs, backups, documents)
      • Sensitive Information in Public Documents/Metadata
      • API Endpoints in JavaScript files
    • Analyze Publicly Available Code Repositories (GitHub, GitLab, Bitbucket) for:
      • Hardcoded Credentials
      • API Keys
      • Sensitive Logic/Endpoints
      • Vulnerable Code Snippets
    • Check Web Archive (Archive.org, other caches) for:
      • Old Versions of Pages
      • Previously Exposed Information or Endpoints
      • Changes in Technology Stack
    • Analyze SSL/TLS Certificates (Subject Alternative Names, Issuer, Validity, Certificate Transparency Logs)
    • Identify Technologies Used (Wappalyzer, WhatWeb, BuiltWith):
      • Web Server (Apache, Nginx, IIS, etc.)
      • Backend Language/Framework (PHP, Java/Spring, Python/Django, Node.js/Express, Ruby/Rails, ASP.NET)
      • Frontend Frameworks/Libraries (React, Angular, Vue.js, jQuery)
      • Content Management System (CMS) (WordPress, Joomla, Drupal, etc.) & Plugins/Themes
      • Web Application Firewall (WAF) Detection (WAFW00F)
      • Analytics & Marketing Tools
    • Search for Publicly Reported Vulnerabilities for Identified Technologies
    • Analyze robots.txt and sitemap.xml
    • Check for Information Disclosure in HTTP Headers
    • Social Media & Forum Research for Employee Posts or Application Mentions
    • Pastebin/Dark Web searches for leaked credentials or data related to the target
  • C. Active Reconnaissance (Light Interaction)
    • Manual Site Crawling & Exploration (as a user)
    • Identify Application Entry Points (Login, Registration, Search, Contact Forms, File Uploads)
    • Identify Application Exit Points (Data Display, Exports, API Responses)
    • Automated Spidering/Crawling (Burp Suite, ZAP, Screaming Frog - respect robots.txt unless permitted to ignore)
    • Directory & File Brute-Forcing (Gobuster, Dirb, Feroxbuster, ffuf) for:
      • Admin Interfaces
      • Backup Files (.bak, .old, .zip, ~)
      • Configuration Files (web.config, .env, wp-config.php)
      • Source Code Files (.java, .php, .cs, .py)
      • Log Files
      • Temporary Files
      • Exposed API Endpoints (common paths, Swagger/OpenAPI definitions)
    • Virtual Host Enumeration (if multiple apps on same IP)
    • Fingerprint Web Server Further (HTTP methods, error pages, specific version probes)
    • Light Port Scanning on Web Server IP (common web ports: 80, 443, 8000, 8080, etc.)
    • Identify Default Credentials for Known Technologies (e.g., Tomcat Manager, JBoss Console)
    • Analyze JavaScript Files for:
      • API Endpoints
      • Hidden Parameters
      • Sensitive Logic
      • Comments with sensitive info
      • Weak Cryptographic Usage
      • DOM XSS Sinks & Sources
    • Check for Source Code Disclosure (e.g., .git folder, .DS_Store, SVN entries)
    • Check for Client-Side Storage (Local Storage, Session Storage, Cookies, IndexedDB) for sensitive data

II. Threat Modeling & Vulnerability Analysis

  • A. Identify Key Assets & Trust Boundaries:
    • User Data (PII, credentials, financial info)
    • Application Data (business secrets, intellectual property)
    • Session Tokens
    • Admin Functionality
    • Backend Systems (databases, internal APIs)
  • B. Analyze Application Architecture:
    • Client-Side vs. Server-Side Logic
    • Single Page Application (SPA) vs. Traditional Multi-Page Application (MPA)
    • API Usage (internal, external, third-party)
    • Data Flow Diagrams (how data is processed, stored, transmitted)
    • Authentication & Authorization Mechanisms
  • C. Map Attack Surface:
    • All HTTP(S) Endpoints (GET, POST, PUT, DELETE, etc.)
    • All Input Parameters (URL, query string, headers, body - JSON, XML, form-data)
    • File Upload Functionality
    • User-Controllable Data in Headers (Referer, User-Agent, Custom Headers)
    • WebSockets / Server-Sent Events
    • Third-Party Integrations & Libraries
  • D. Automated Vulnerability Scanning (with caution and verification):
    • Dynamic Application Security Testing (DAST) tools (Burp Suite Pro, OWASP ZAP, Acunetix, Netsparker)
    • Content Management System (CMS) specific scanners (WPScan, JoomScan, Droopescan)
    • API specific scanners
    • JavaScript library vulnerability scanners (Retire.js)
    • Review and Manually Verify All Scanner Findings (critical to eliminate false positives)

III. Authentication Testing

  • A. Enumeration:
    • User Enumeration via Login Page (different error messages for valid/invalid users)
    • User Enumeration via Password Reset Page
    • User Enumeration via Registration Page (username already exists)
    • User Enumeration via API endpoints
  • B. Password Policy:
    • Check for Minimum/Maximum Length Requirements
    • Check for Complexity Requirements (uppercase, lowercase, numbers, symbols)
    • Check for Password History Restriction
    • Check for Password Expiration & Forced Reset
    • Check against Common Password Lists / Dictionary Attacks
    • Check for Easily Guessable "Hint" Questions/Answers
  • C. Brute-Force Attacks:
    • Login Form Brute-Force (users, passwords)
    • Password Reset Token Brute-Force
    • CAPTCHA Bypass/Weakness Testing
    • Account Lockout Mechanism Testing (existence, threshold, duration, reset)
    • Rate Limiting on Authentication Attempts
    • Multi-Factor Authentication (MFA/2FA) Token Brute-Force (if applicable)
  • D. Credentials Transport & Storage:
    • Credentials Sent Over HTTPS (no HTTP)
    • Autocomplete Prevention on Password Fields (autocomplete="off" or "new-password")
    • No Hardcoded Credentials in Client-Side Code
    • No Default Credentials for Admin/Test Accounts
    • Secure Password Storage (hashing with strong algorithm and salt, e.g., Argon2, scrypt, bcrypt, PBKDF2)
  • E. Session Management for Authentication:
    • Session Token Generation (randomness, length, uniqueness)
    • Session Token Transmission (HTTPS only, HttpOnly flag, Secure flag for cookies)
    • Session Timeout (idle and absolute)
    • Session Fixation Vulnerabilities
    • Session Hijacking (if tokens are predictable or exposed)
    • Secure Logout (session invalidated server-side)
    • Concurrent Session Management
    • "Remember Me" Functionality Security (long-lived tokens, secure storage)
  • F. Multi-Factor Authentication (MFA/2FA):
    • MFA Bypass Techniques (e.g., response manipulation, backup code issues)
    • Weak OTP Generation/Validation
    • Information Disclosure of MFA Status
    • MFA Trust Mechanisms (e.g., trust this device) and their bypasses
    • Brute-forcing recovery codes
    • Social engineering MFA codes
  • G. OAuth / OpenID Connect / SAML Testing:
    • Weak Redirect URI Configuration (Open Redirect, token theft)
    • CSRF on Authorization Flow (state parameter misuse)
    • Authorization Code Interception / Replay
    • Implicit Grant Flow Misuse (token leakage via browser history/Referer)
    • JWT Vulnerabilities (alg=none, weak secrets, public key confusion, kid injection)
    • SAML Assertion Tampering, Signature Wrapping, XML Injection
    • Insufficient Scope Validation
    • Client Secret Leakage
  • H. Password Reset & Account Recovery:
    • Token Generation (randomness, expiry, single-use)
    • Token Leakage (e.g., in URL, via Referer header)
    • Information Disclosure During Reset Process (e.g., confirming email existence)
    • Host Header Injection for Password Reset Links
    • No Link Between Session and Reset Process
    • Email/SMS Verification Code Brute-Force/Bypass

IV. Authorization Testing

  • A. Horizontal Privilege Escalation:
    • Accessing Data/Functionality of Other Users with Same Role
    • Modifying Identifiers in URLs, POST data, Headers, Cookies (IDOR)
    • Testing All Functions with User A's Session, Then User B's Identifiers
  • B. Vertical Privilege Escalation:
    • Accessing Admin/Higher-Privileged Functionality with Lower-Privileged User Session
    • Forced Browse to Admin URLs
    • Parameter Tampering to Invoke Privileged Functions
    • Exploiting Chained Vulnerabilities to Elevate Privileges
  • C. Insecure Direct Object References (IDOR):
    • Testing for IDOR in GET/POST parameters, JSON bodies, Cookies, Headers
    • Testing with numeric IDs, GUIDs, usernames, filenames
    • Checking for IDOR in API endpoints
    • Testing for IDOR in multi-tenant applications
  • D. Missing Function-Level Access Control:
    • Directly Calling Privileged Functions/API Endpoints Without Proper Checks
    • Accessing Admin Panels/Functions While Authenticated as a Regular User
  • E. Role-Based Access Control (RBAC) Bypass:
    • Manipulating Role Parameters
    • Exploiting Flaws in Role Assignment Logic
    • Path Traversal to Access Restricted Resources Based on Role
  • F. Client-Side Authorization Control Bypass:
    • Disabling JavaScript
    • Modifying JavaScript Variables
    • Intercepting and Modifying Requests in Burp/ZAP to Bypass Client-Side UI Restrictions
  • G. Insecure API Authorization:
    • Missing or Weak API Key/Token Validation
    • Broken Object Level Authorization (BOLA) in APIs
    • Broken Function Level Authorization (BFLA) in APIs
    • Mass Assignment leading to privilege escalation via API

V. Session Management Testing

  • A. Session Token Properties:
    • Meaningful Session Tokens (avoid sequential or easily guessable tokens)
    • Session Token Length and Entropy
    • HttpOnly Flag on Cookies
    • Secure Flag on Cookies
    • SameSite Attribute (Lax, Strict, None) on Cookies & CSRF implications
    • Cookie Path and Domain Scope (Path=/, Domain=) - ensure not too broad
    • Cookie Expiration and Max-Age
  • B. Session Lifecycle:
    • Session Invalidation on Logout
    • Session Invalidation on Password Change/Reset
    • Session Invalidation on Idle Timeout
    • Session Invalidation on Absolute Timeout
    • Session Renewal Mechanisms (sliding sessions) security
    • Handling of Concurrent Logins (allow, disallow, notify)
  • C. Session Puzzling/Fixation:
    • Forcing Session IDs via GET/POST Parameters or Headers
    • Session Fixation Before Authentication
    • Session Adoption Vulnerabilities
  • D. Cross-Site Request Forgery (CSRF):
    • Absence of Anti-CSRF Tokens for State-Changing Requests
    • Weak Anti-CSRF Token Implementation (not tied to session, predictable, reusable)
    • CSRF on Login/Logout Forms (less common but possible impact)
    • Testing for CSRF in AJAX requests
    • Testing for CSRF with different HTTP methods (GET, POST, PUT, DELETE)
    • Use of SameSite cookie attribute as a defense and its limitations
  • E. JSON Web Token (JWT) Specifics:
    • alg:none vulnerability
    • HMAC with Public Key (Algorithm Confusion)
    • Weak Secret Keys (brute-forceable)
    • kid parameter injection / path traversal
    • Sensitive data in JWT payload (non-encrypted)
    • Lack of exp (expiration) claim or improper validation
    • iat (issued at) and nbf (not before) claim validation
    • JKU/X5U header vulnerabilities (SSRF to fetch malicious keys)
    • Replay attacks if jti (JWT ID) is not used or validated for uniqueness
    • Signature stripping

VI. Input Validation & Sanitization Testing (Injection Vulnerabilities)

  • A. Cross-Site Scripting (XSS):
    • Reflected XSS:
      • Testing all input fields, URL parameters, HTTP headers
      • Using various XSS payloads (script tags, event handlers, different encodings)
      • Testing in HTML context, JavaScript context, attribute context, URL context
    • Stored XSS:
      • Testing inputs that are stored and later displayed (comments, profiles, forum posts, filenames)
      • Testing for second-order stored XSS (data stored via one function, XSS triggers via another)
    • DOM-based XSS:
      • Identifying sources (e.g., location.hash, document.referrer) and sinks (e.g., innerHTML, document.write, eval)
      • Manually crafting payloads targeting DOM manipulation
      • Using browser developer tools to trace data flow
    • Blind XSS:
      • Injecting payloads into backend systems (e.g., log viewers, admin panels) that might trigger later
      • Using XSS Hunter or similar services
    • XSS Filter Evasion Techniques:
      • Encoding (HTML entities, URL encoding, Base64)
      • Case variations
      • Null bytes
      • Obfuscated JavaScript
      • Using less common event handlers/tags
    • Content Security Policy (CSP) Analysis & Bypass:
      • Review CSP headers for misconfigurations (unsafe-inline, unsafe-eval, overly broad sources)
      • JSONP abuse for CSP bypass
      • Dangling markup injection
  • B. SQL Injection (SQLi):
    • In-band SQLi:
      • Error-based (forcing database errors revealing data/schema)
      • Union-based (combining results from another table)
    • Inferential (Blind) SQLi:
      • Boolean-based (observing true/false responses)
      • Time-based (injecting delays to infer data)
    • Out-of-band SQLi:
      • Using database functions to exfiltrate data via DNS, HTTP requests (e.g., xp_dirtree, UTL_HTTP, LOAD_FILE)
    • Testing Locations:
      • URL Parameters (GET)
      • Form Fields (POST)
      • HTTP Headers (Cookie, User-Agent, Referer, Custom Headers)
      • JSON/XML Payloads
      • Stored Procedures / Second Order SQLi
    • Database Specific Payloads:
      • MySQL, MSSQL, PostgreSQL, Oracle, SQLite
    • WAF Bypass Techniques for SQLi:
      • Comments, whitespace, case variations, encoding, null bytes, alternative syntax
    • NoSQL Injection:
      • Targeting MongoDB, CouchDB, etc.
      • Operator injection ($gt, $ne, $where), JavaScript injection
  • C. OS Command Injection:
    • Testing inputs used in system commands (filenames, user inputs to scripts)
    • Using command separators (;, |, &&, ||, \n, `)
    • Blind command injection techniques (time delays, output redirection to webroot, out-of-band)
    • Testing file upload functionalities for command injection via filenames or metadata
  • D. LDAP Injection:
    • Testing inputs used in LDAP queries (login forms, search functions)
    • Using LDAP metacharacters (, (, ), \, &, |, !)
  • E. XPath Injection / XXE (XML External Entity) Injection:
    • XPath Injection:
      • Testing inputs used in XPath queries in XML-based applications
    • XXE Injection:
      • Testing XML parsers for XXE vulnerabilities (file uploads, SOAP requests, other XML inputs)
      • Exploiting XXE for:
        • File disclosure (file:///etc/passwd)
        • SSRF (accessing internal resources)
        • Denial of Service (billion laughs attack)
        • Port scanning internal networks
      • Testing for out-of-band XXE
  • F. Server-Side Template Injection (SSTI):
    • Identifying template engines (Jinja2, Twig, Freemarker, Velocity, ERB, etc.)
    • Using polyglot payloads to detect SSTI
    • Crafting payloads for RCE or information disclosure based on the identified engine
    • Testing in user profiles, custom templates, email generation, PDF generation
  • G. HTTP Header Injection / Response Splitting:
    • Injecting CRLF characters (\r\n) into headers controlled by user input
    • Testing for cache poisoning, XSS, session fixation via header injection
    • Testing for HTTP Response Splitting
  • H. NoSQL Injection (Re-iterated for specific focus):
    • Check if user inputs directly construct NoSQL queries
    • Try injecting NoSQL operators (e.g., MongoDB: $ne, $regex, $where for JS execution)
    • Test for data type manipulation that could lead to unexpected query behavior
  • I. Host Header Injection:
    • Manipulating the Host header for:
      • Password reset poisoning
      • Cache poisoning
      • SSRF against internal hosts that trust the Host header
      • Accessing internal applications if a reverse proxy uses the Host header for routing
  • J. CSV / Formula Injection:
    • Testing "Export to CSV/Excel" functionalities
    • Injecting payloads like =cmd|' /C calc'!A0 or =HYPERLINK(...) that execute when the CSV is opened
  • K. Insecure File Uploads:
    • Bypassing File Type Restrictions (magic bytes, extensions, Content-Type header)
    • Uploading Web Shells (.php, .asp, .jsp, .aspx, .phtml)
    • Uploading Files with Malicious Payloads (XSS in SVG, XXE in XML/DOCX)
    • Directory Traversal on File Upload Path (../../shell.php)
    • Double Extension Attack (shell.php.jpg)
    • Null Byte Injection in Filename (shell.php%00.jpg)
    • Testing for Race Conditions during file upload and processing
    • Large File Upload DoS
    • Pixel Flood Attack (ImageMagick/GraphicsMagick vulnerabilities)
    • Antivirus Bypass for uploaded malware
    • Overwriting existing critical files

VII. Server-Side Vulnerabilities

  • A. Server-Side Request Forgery (SSRF):
    • Identifying functionalities that make requests based on user input (URL fetchers, PDF generators, webhook integrations)
    • Testing with http://, https://, file:///, ftp://, gopher://, dict:// schemes
    • Accessing internal IP addresses and ports (e.g., 127.0.0.1, 169.254.169.254, internal RFC1918 ranges)
    • Interacting with cloud metadata services (AWS EC2, Azure IMDS, GCP Metadata Server)
    • Bypassing SSRF defenses (blacklists, whitelists, open redirects)
    • Blind SSRF detection techniques
  • B. Security Misconfigurations (Server Level):
    • Default Credentials (admin panels, databases, middleware)
    • Directory Listing Enabled
    • Verbose Error Messages Disclosing Sensitive Information (stack traces, paths, config details)
    • Unnecessary Services/Features Enabled (e.g., debug modes, sample applications, HTTP methods like PUT/DELETE if not used)
    • Outdated Software Versions (web server, OS, libraries - check for public CVEs)
    • Misconfigured HTTP Headers (Missing Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy)
    • Information Leakage via Headers (Server, X-Powered-By, X-AspNet-Version)
    • Insecure Cross-Origin Resource Sharing (CORS) Configuration (Access-Control-Allow-Origin: * or reflecting origin)
    • Open Ports for Unnecessary Services
    • Weak SSL/TLS Configurations (old protocols like SSLv3/TLSv1.0/1.1, weak ciphers, BEAST, POODLE, Heartbleed, Sweet32)
    • Exposed Management Interfaces (Tomcat Manager, JBoss Admin Console, phpMyAdmin)
    • Insecure handling of .git directory or other VCS metadata
    • Path Traversal at the Web Server Level (e.g., misconfigured aliases)
  • C. Using Components with Known Vulnerabilities:
    • Identifying all third-party libraries (client-side and server-side)
    • Checking versions against vulnerability databases (NVD, CVE Details, Snyk, Retire.js for JS)
    • Testing for known exploits for identified vulnerable components
  • D. Information Disclosure:
    • Sensitive Data in Comments (HTML, JS, CSS)
    • Error Message Content (stack traces, database errors, internal paths)
    • Backup Files (.bak, .swp, .old, ~)
    • Configuration Files Exposed (.env, web.config, appsettings.json)
    • API Key Leakage (client-side code, public repositories, error messages)
    • User Profile Information Leakage (e.g., via sequential IDs or search features)
    • Debug Parameters revealing sensitive info (?debug=true)
  • E. Denial of Service (DoS) - Use with EXTREME caution and explicit permission:
    • Resource Exhaustion (CPU, memory, disk space) via legitimate-looking requests
    • Regex DoS (ReDoS) in input validation
    • XML Bomb / Billion Laughs (for XXE-vulnerable parsers)
    • Large File Uploads
    • Slow HTTP Attacks (Slowloris, Slow POST)
    • Asymmetric Resource Consumption (e.g., password hashing, complex search queries)
    • Logic flaws leading to resource exhaustion
    • Testing for lack of rate limiting on expensive operations

VIII. API Security Testing (REST, GraphQL, SOAP, WebSockets)

  • A. General API Vulnerabilities (Applicable to REST, GraphQL, etc.):
    • Broken Authentication (as per Section III)
    • Broken Authorization (BOLA/IDOR, BFLA - as per Section IV)
    • Excessive Data Exposure (API returning more data than necessary)
    • Mass Assignment (binding client-controlled data to internal object properties without validation)
    • Lack of Resources & Rate Limiting (DoS, brute-force)
    • Security Misconfiguration (verbose errors, default creds, CORS, HTTP headers)
    • Injection Vulnerabilities (SQLi, NoSQLi, Command Inj. in API parameters)
    • Improper Assets Management (e.g., old API versions still active and vulnerable, exposed dev/staging APIs)
    • Insufficient Logging & Monitoring (for detecting attacks)
  • B. REST API Specifics:
    • HTTP Method Tampering (e.g., using GET instead of POST, or PUT/DELETE when not intended)
    • Insecure handling of Content-Type (e.g., expecting JSON but accepting XML leading to XXE)
    • API Key Management (secure storage, rotation, privilege scoping)
    • Parameter Pollution (HTTP Parameter Pollution - HPP)
    • Unprotected API endpoints (especially for internal or sensitive operations)
    • Versioning issues (e.g., /v1/ vulnerable while /v2/ is fixed)
  • C. GraphQL Specifics:
    • Introspection Query Enabled (allowing attackers to map the entire schema)
    • Batching Attacks (sending multiple queries in one request to cause DoS)
    • Circular Queries (DoS)
    • Field Duplication (DoS)
    • Deeply Nested Queries / Query Depth Limiting
    • Alias Overloading
    • Authorization Bypass via Nested Objects or mutations
    • Suggestions Enabled (can leak field/type names)
    • Injection within GraphQL arguments
  • D. SOAP API Specifics:
    • XML Injection / XXE in SOAP messages
    • WSDL Enumeration and Analysis
    • Replay Attacks with SOAP messages
    • WS-Security Misconfigurations
  • E. WebSockets / Socket.IO Specifics:
    • Unauthenticated/Unauthorized Access to WebSocket Endpoints
    • Cross-Site WebSocket Hijacking (CSWSH)
    • Data Injection through WebSocket Messages (XSS, SQLi if data is processed insecurely)
    • Lack of Message Encryption (if wss:// is not used)
    • Denial of Service via message flooding
    • Weak origin validation

IX. Business Logic Vulnerabilities

  • A. All
    • Identify Application Workflows (user registration, password reset, shopping cart, payment processing, approval chains)
    • Test for Flaws in Multi-Stage Processes (e.g., skipping steps, manipulating state)
    • Price Manipulation (tampering with prices in requests or client-side)
    • Discount/Coupon Abuse
    • Order Modification/Cancellation Flaws
    • Approval Process Bypass
    • Exploiting Race Conditions in Business Logic (e.g., redeeming a voucher multiple times)
    • Feature Abuse (e.g., spamming via contact forms, review bombing)
    • Unexpected Application State Manipulation
    • Data Validation Flaws Beyond Security (e.g., allowing negative quantities)
    • Information Leakage through Business Logic Flows
    • Exploiting Trust Between Application Components
    • Circumventing Workflow Rules
    • Unauthorized Fund Transfers or Data Modification

X. Cryptography & Data Protection

  • A. All
    • Use of Weak or Deprecated Cryptographic Algorithms (MD5, SHA1 for hashing passwords, DES, RC4 for encryption)
    • Insufficient Key Length or Weak Key Generation
    • Hardcoded Cryptographic Keys in Client-Side or Server-Side Code
    • Missing Encryption for Sensitive Data at Rest (databases, files)
    • Missing Encryption for Sensitive Data in Transit (ensure TLS 1.2+ everywhere, strong ciphers)
    • Predictable IVs (Initialization Vectors) or Nonce Reuse in Symmetric Encryption
    • Padding Oracle Attacks (if CBC mode with PKCS#7 padding is used and error messages leak info)
    • Insecure Random Number Generation for Security-Sensitive Values (session tokens, CSRF tokens, password reset tokens)
    • Client-Side Cryptography Implementation Weaknesses (often easily bypassed)
    • Information Leakage via Cryptographic Error Messages
    • Data Masking Failures (e.g., credit card numbers not properly masked in logs or UI)

XI. Error Handling & Logging

  • A. All
    • Verbose Error Messages (stack traces, internal paths, SQL errors, software versions)
      • Test different inputs, invalid parameters, unexpected data types
    • Generic vs. Specific Error Messages (avoid revealing too much, but provide enough for user understanding)
    • Inconsistent Error Handling Across Application
    • Improper Logging (sensitive data in logs - passwords, API keys, session tokens, PII)
    • Insufficient Logging (not logging security-relevant events - logins, failed logins, access control failures, input validation failures)
    • Logs Accessible by Unauthorized Users
    • Log Injection / Log Forging (injecting fake log entries or CRLF to break log format)
    • Error Codes that Reveal Too Much Information

XII. Client-Side Security (Beyond DOM XSS)

  • A. All
    • Insecure Use of postMessage() API (missing origin validation, data validation)
    • Insecure Data Storage in Browser (Local Storage, Session Storage, Cookies - check for sensitive info)
    • Client-Side URL Redirects (Open Redirect if user input controls destination without validation)
    • Clickjacking / UI Redressing (ensure X-Frame-Options or CSP frame-ancestors are used)
    • Cross-Origin Resource Sharing (CORS) Misconfigurations allowing unauthorized origins
    • Subresource Integrity (SRI) Not Used for External JS/CSS
    • Outdated or Vulnerable JavaScript Libraries (Retire.js)
    • Improperly Sanitized Data Displayed from Client-Side Storage
    • WebAssembly (WASM) vulnerabilities (if used, memory corruption, logic flaws)
    • Service Worker vulnerabilities (interception, cache poisoning)

XIII. Reporting & Post-Assessment

  • A. All
    • Document All Findings (description, vulnerable URLs/parameters, PoC steps, screenshots/videos)
    • Assess Impact and Likelihood (CVSS scoring or similar)
    • Provide Clear Remediation Guidance (specific to the vulnerability and technology)
    • Executive Summary for Management
    • Technical Details for Development Teams
    • Positive Findings (what the application does well)
    • Strategic Recommendations for Overall Security Posture Improvement
    • (Optional) Retest after fixes are applied.