Vulnerability Detection

Analyze code where user-controlled input is used to construct database queries. Look for unsanitized input concatenation or ORM methods susceptible to injection. On mobile/desktop, check local SQLite/database usage.

Analyze code where user-controlled input is used to construct queries in NoSQL databases (MongoDB, etc.). Look for insecure use of operators ($where, etc.) or construction of query objects with unsanitized data. Typically a backend vulnerability.

Analyze code where user-controlled input might be passed to system commands (e.g., exec, system, popen). Look for unsanitized input used in command strings. Check native code interactions on mobile/desktop or OS libraries.

Analyze code where user-controlled input is evaluated or executed directly (e.g., eval, exec, script engines) without proper validation or sandboxing. Check WebViews, dynamic code loading, or embedded scripting on mobile/desktop/libraries.

Analyze code where serialized objects from untrusted sources (user input, files, network) are deserialized without proper validation, potentially leading to remote code execution (e.g., pickle, Java/PHP serialization). Can occur on client/server.

Analyze code where user-controlled input (URLs, hostnames, paths) is used to make server-side HTTP requests to internal or external resources without proper validation. Check if mobile/desktop apps make requests based on external input.

Analyze code where user-controlled input is directly embedded into server-side templates without proper sanitization, potentially allowing code execution within the template engine.

Analyze code or server configurations where user-controlled input might be included in files processed by the web server for SSI directives (e.g., <!--#include file="..." -->), potentially allowing file inclusion or command execution if SSI execution is enabled.

Scan code for hardcoded API keys, passwords, private keys, database connection strings, default credentials, or other sensitive secrets.

Analyze code where user-controlled input is used in file paths (reading, writing, including files) without proper sanitization, potentially allowing access to restricted files (LFI/RFI on server, local file access on mobile/desktop/libraries).

Analyze client-side code (JavaScript) where user-controlled input (e.g., from URL fragments, parameters, postMessage) is used to construct URLs or paths for API requests or navigation, potentially leading to unintended resource access or redirection. Relevant for WebViews/JS frameworks on mobile/desktop.

Analyze code that parses XML input (local or fetched). Check if external entity processing is disabled and if user input can influence XML structure leading to XXE.

Analyze code handling file uploads (client-side checks, server-side validation). Check for validation of file types, names, sizes, and storage locations to prevent execution of uploaded files or path traversal.

Analyze code for sensitive endpoints or functions lacking authentication checks (e.g., missing decorators, middleware). Check login flows, parameter manipulation, or local auth bypasses on mobile/desktop.

Analyze password policies, session termination, account deletion processes, and recovery mechanisms for security flaws. Includes local credential handling on desktop/mobile.

Analyze code to verify that authorization checks (roles, permissions) are correctly applied server-side after authentication. Check for logic flaws allowing unauthorized access to functions or data. Check local authorization logic on desktop/mobile if applicable.

Analyze code for functions allowing insecure changes to roles/permissions or invocation of admin functions by lower-privileged users. Check local privilege handling on desktop/mobile/OS libraries.

In multi-tenant applications (i.e., if the system supports tenants/organizations), analyze code to ensure all data queries and operations are strictly filtered by the authenticated user's tenant ID. If the application is not multi-tenant, this item may not be relevant.

Analyze code where user-controlled identifiers (IDs in URLs, parameters) are used to access resources without verifying the user's authorization for that specific resource. Check how desktop/mobile apps construct requests.

Analyze functions like registration, profile modification, password reset, etc., for logic flaws enabling account takeover (predictable tokens, lack of verification, etc.). Includes local credential/token handling on desktop/mobile.

Analyze the logic for generating, verifying, and managing OTP/MFA codes for bypass vulnerabilities (rate limiting, predictability, skipping steps). Check client-side handling on desktop/mobile.

Analyze JWT usage: signature verification (alg 'none', weak keys), claim validation (exp, iss, aud), insecure storage (e.g., localStorage, insecure mobile/desktop storage).

If SAML is used, analyze processing code: signature validation, XXE in parsing, ACS logic, condition/audience validation.

Analyze OAuth/OIDC flows: 'state' parameter validation (CSRF), insecure code handling, implicit flow issues, redirect URI validation. Check client-side implementation on mobile/web/desktop.

Analyze multi-tenant apps with tenant-configurable IDPs (SAML/OIDC): configuration security (SSRF, redirects), parsing (XXE), assertion processing (signature bypass, claim injection), provisioning, Tenant ATO risks.

Analyze code for check-then-act sequences without locking, non-atomic operations, lack of DB constraints, potentially leading to inconsistent states or bypasses. Can occur client/server.

Analyze code where user input is reflected in HTML/JS without proper contextual encoding (reflected, stored). Check WebViews, embedded browsers, or dynamic HTML rendering on mobile/desktop.

Analyze client-side JS where input from sources (URL, postMessage) flows to sinks (eval, innerHTML, location) without sanitization (DOM-XSS, Open Redirect). Relevant for WebViews/JS frameworks on mobile/desktop.

Analyze code where user input is inserted into HTTP headers without sanitizing CR (\r) and LF (\n), allowing header injection or response splitting.

Analyze how the application processes and trusts incoming HTTP headers such as Host, X-Forwarded-For, X-Forwarded-Host, and other client-controllable headers. Look for vulnerabilities where manipulation of these headers can lead to bypassing security controls (e.g., IP-based restrictions), web cache poisoning, SSRF, incorrect application logic, or eliciting other unintended behaviors. Ensure headers are properly validated before use in security-sensitive contexts.

Analyze code where user input determines redirection targets without validation against an allow-list. Check WebViews/custom scheme handlers/embedded browsers on mobile/desktop.

Analyze code for exposure of sensitive data: server details (errors, logs, comments), user info (verbose responses, PII exposure, insecure logging). Specifically, look for APIs or data structures that return more data than necessary for the functionality, such as exposing entire user objects/models (including sensitive fields like API keys, internal flags, or unnecessary PII) when only a subset of information is required. Check local storage/logs/configs on mobile/desktop.

Scan code for weak algorithms (MD5, SHA1, DES), insecure modes (ECB), non-constant time comparisons, insecure randomness, lack of proper encryption/hashing for sensitive data.

Analyze state-changing requests: check anti-CSRF token implementation/validation, SameSite cookies, standard headers. Consider CSRF via mobile deeplinks or WebViews.

Analyze code and configuration files (e.g., Nginx, cloud configs, Dockerfiles, IaC) for security misconfigurations such as debug modes, default credentials, insecure headers/cookies, permissive CORS, verbose errors, or improper permissions. Also, review mobile/desktop app manifests, build settings, and local application configurations.

Analyze code where user input constructs LDAP queries without sanitization. Typically a backend vulnerability.

Analyze code generating downloadable/exportable files (CSV, XLSX) using user input. Check sanitization/escaping of input starting with (=, +, -, @, ＝).

Analyze code generating documents (PDF, DOCX) using libraries. Look for insecure input use leading to XSS, SSRF, command injection, or library exploits. Can occur client/server.

Analyze code (esp. C/C++, native mobile/desktop/libraries) for arithmetic operations on user-controlled numbers without bounds checking, potentially leading to bypasses or unexpected behavior.

(JavaScript/Node.js) Analyze code for patterns (recursive merge, property definition by path) where user input can modify global object prototypes (potential bypass, DoS, RCE). Relevant for WebViews/JS frameworks on mobile/desktop.

Analyze WebSocket handler code: input validation, authz checks, XSS in messages. Check for Cross-Site WebSocket Hijacking (CSWSH) via weak origin checks. Check client-side handling on desktop/mobile.

Review application and server configuration files and related code for insecure cache settings. This includes improper Vary header usage, misconfigured framework cache settings, or incorrect explicit cache control headers that could lead to sensitive data being cached incorrectly, cache poisoning, or cache deception based on the configuration itself.

Analyze code for DoS patterns: ReDoS, expensive operations based on input without limits, resource exhaustion (zip bombs), algorithmic complexity attacks. Check local resource handling on desktop/mobile/libraries.

Analyze code where frameworks bind user input to objects/models. Check if filtering prevents setting internal/security-sensitive properties.

Analyze code where input type, format, length, or range isn't validated before use in logic, potentially altering control flow, bypassing rules, or causing inconsistent states.

Analyze payment/cart/pricing code. Check for client-side price manipulation bypasses, insecure validation of items/quantities, currency/rounding issues, discount/coupon abuse, and race conditions during the initial purchase process (e.g., using credits multiple times).

Analyze logic for third-party payment webhooks (e.g., Stripe, PayPal) and subscription lifecycle management. Verify webhook signature validation. Ensure all relevant events are handled to correctly update user/service status (e.g., charge.refunded, customer.subscription.deleted, invoice.payment_failed). Check for race conditions in status updates and insecure payment status validation.

Analyze code (esp. C/C++, native mobile/desktop/libraries) for functions handling user input (strcpy, gets, memcpy) without bounds checking (memory corruption, code execution).

Analyze code (esp. C/C++, native mobile/desktop/libraries) for pointers used after freeing memory (crashes, data corruption, code execution).

Analyze code (esp. C/C++, native mobile/desktop/libraries) for attempts to free the same memory region twice (memory corruption, exploitation).

Analyze code (esp. C/C++, native mobile/desktop/libraries) where user input is used directly as format string argument (printf, sprintf), allowing memory read/write.

Analyze mobile app code for storage of sensitive data (credentials, PII, tokens) in insecure locations (e.g., SharedPreferences without encryption, external storage, logs, insecure databases) accessible to other apps or users with physical access.

Analyze mobile app code for the presence and effectiveness of root/jailbreak detection, anti-debugging, and emulator detection mechanisms. Check if these checks can be easily bypassed (e.g., client-side checks only, predictable logic).

Analyze mobile app code handling custom URL schemes (deeplinks). Check for lack of input validation on parameters (potential for XSS, Path Traversal, SQLi if passed to backend), CSRF risks (if actions triggered without user intent), or Open Redirects.

Analyze mobile app code using WebViews. Check if JavaScript execution is enabled (setJavaScriptEnabled(true)), if the JavaScript bridge (addJavascriptInterface) exposes sensitive native functions, and if content loaded is properly validated (potential for XSS, loading untrusted content).

Analyze mobile app network configuration and code. Check for disabled App Transport Security (ATS) on iOS, cleartext traffic allowed on Android, lack of certificate pinning, or insecure TLS/SSL configurations.

Analyze mobile app code that reads/processes files from external storage or locations accessible by other apps. Check for Path Traversal, lack of validation on file content, or insecure handling that could lead to code execution or data leakage if a malicious app modifies the file.

Analyze mobile app code using IPC mechanisms (e.g., Intents, Content Providers, Broadcast Receivers on Android; XPC on iOS). Check for improperly protected components (missing permissions, intent filters too broad), data leakage, or ability for malicious apps to send crafted messages to trigger unintended actions.

Analyze mobile app code implementing biometric authentication. Check if the authentication result is validated server-side or if a client-side bypass is possible. Ensure fallback mechanisms are secure.

Analyze smart contract code for reentrancy vulnerabilities, where external calls can re-enter the calling contract before the initial execution completes, potentially leading to state inconsistencies or fund drainage. Look for patterns like call-after-state-change instead of check-effects-interactions.

Analyze smart contract code for integer overflow or underflow vulnerabilities in arithmetic operations, especially those involving token balances or critical calculations. Ensure use of safe math libraries.

Analyze smart contract logic that relies on block.timestamp or block.number for critical operations (e.g., unlocking funds, determining winners). These can be manipulated by miners to some extent.

Analyze smart contracts for functions or loops that might consume unbounded gas, leading to denial of service for users or the contract itself. Check for patterns like iterating over large arrays or complex computations that can exceed block gas limits.

Analyze smart contract logic for vulnerabilities where the outcome of a transaction can be influenced by the order in which transactions are mined. Look for scenarios where an attacker can observe a transaction and submit their own to exploit the system (e.g., decentralized exchanges, auctions).

Analyze smart contracts that rely on external data sources (oracles). Check how data is fetched, validated, and used. Look for vulnerabilities where the oracle can be manipulated or its data can be influenced to exploit the contract.

Analyze smart contract code using delegatecall. Ensure that the target contract's storage layout is compatible and that delegatecall is not used with untrusted contracts, which could lead to storage corruption or arbitrary code execution in the context of the calling contract.

Analyze smart contract functions for proper access control mechanisms (e.g., onlyOwner, require(msg.sender == authorized_address)). Look for sensitive functions that can be called by unauthorized users.

Perform a general review of the smart contract's business logic to identify flaws, edge cases, or unintended behaviors that could be exploited. This requires understanding the contract's intended purpose.

Analyze smart contracts that require randomness. Using on-chain sources like blockhash or block.timestamp for randomness can be predictable or influenced by miners. Check for reliance on such sources for critical security decisions.

Analyze server, proxy, and application gateway configurations (e.g., Nginx, Apache, HAProxy, CloudFront, API Gateway configs, IaC like Terraform/CloudFormation) for settings that could enable HTTP Request Smuggling. Look for configurations that lead to ambiguous request parsing between frontend and backend systems, such as mishandling of Content-Length and Transfer-Encoding headers, or incorrect processing of chunked encoding. This can allow attackers to prepend or append data to other users' requests.

Analyze code for Cross-Site Script Inclusion (XSSi) and Cross-Site Leaks (XS-Leaks). Look for sensitive data (JSON, CSV, images) returned without proper isolation (e.g., missing X-Content-Type-Options: nosniff, COOP/COEP headers) or accessible via script tags/frames from other origins. Check for side-channels (timing, error events) that could leak information across origins.

Analyze Infrastructure as Code (IaC) or configuration files for insecure cloud storage settings (e.g., S3 buckets, Azure Blobs). Look for public access, lack of encryption, missing logging/versioning, or overly permissive bucket policies.

Analyze IaC and cloud configurations for overly permissive Identity and Access Management (IAM) policies. Look for use of wildcards (*), lack of least privilege, hardcoded IAM credentials, or insecure role assumption trust policies.

Analyze Dockerfiles and Kubernetes manifests. Look for running as root, missing user directives, use of 'latest' tags, sensitive mounts, privileged mode, or lack of resource limits.

Analyze Terraform, CloudFormation, or other IaC files for security best practices. Look for unencrypted resources, open security groups (0.0.0.0/0), missing backups, or insecure default settings.

Analyze code to identify if the application uses different parsers for the same data format (e.g., JSON, YAML, XML) across different components (e.g., frontend vs. backend, proxy vs. application). Discrepancies in parsing can be exploited to bypass security controls, leading to vulnerabilities like authentication bypass, XSS, or SQL injection. For example, a proxy might see one set of parameters while the backend application sees another.

Check if the GraphQL endpoint has introspection enabled in production environments. Introspection allows attackers to query the entire schema, revealing all available queries, mutations, subscriptions, types, and fields. This information leakage significantly aids attackers in understanding the API and discovering potential vulnerabilities.

Investigate if the GraphQL endpoint allows for query batching, where multiple queries can be sent in a single HTTP request. If not properly restricted, attackers can abuse this feature to execute a large number of complex queries simultaneously, overwhelming the server and causing a Denial of Service (DoS) attack.

Analyze payment/cart/pricing code: client-side price manipulation bypasses, insecure payment status validation, race conditions (discounts/credits), currency/rounding issues, quantity/item validation.

Analyze test files (unit, integration, e2e) to understand business logic, edge cases, and potential security gaps. Look for commented-out security tests, tests for known bugs, or test data that reveals sensitive logic.

Analyze code interacting with Large Language Models (LLMs). Look for Prompt Injection vulnerabilities, insecure handling of LLM outputs (XSS via LLM), or leakage of sensitive context in prompts.

Review project documentation and code comments. Discrepancies between documentation and implementation often reveal bugs or security issues. Comments may contain TODOs, warnings, or explanations of complex logic that hint at vulnerabilities.