{"id":21400614,"url":"https://github.com/cybersecurityup/web-pentest-checklist","last_synced_at":"2026-02-09T12:36:23.079Z","repository":{"id":188821096,"uuid":"679493137","full_name":"CyberSecurityUP/Web-PenTest-Checklist","owner":"CyberSecurityUP","description":null,"archived":false,"fork":false,"pushed_at":"2023-08-17T01:20:26.000Z","size":81,"stargazers_count":52,"open_issues_count":0,"forks_count":21,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-08-17T16:48:22.095Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/CyberSecurityUP.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2023-08-17T01:19:48.000Z","updated_at":"2025-06-10T06:12:05.000Z","dependencies_parsed_at":"2023-08-17T03:13:23.449Z","dependency_job_id":null,"html_url":"https://github.com/CyberSecurityUP/Web-PenTest-Checklist","commit_stats":null,"previous_names":["cybersecurityup/web-pentest-checklist"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/CyberSecurityUP/Web-PenTest-Checklist","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CyberSecurityUP%2FWeb-PenTest-Checklist","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CyberSecurityUP%2FWeb-PenTest-Checklist/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CyberSecurityUP%2FWeb-PenTest-Checklist/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CyberSecurityUP%2FWeb-PenTest-Checklist/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/CyberSecurityUP","download_url":"https://codeload.github.com/CyberSecurityUP/Web-PenTest-Checklist/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/CyberSecurityUP%2FWeb-PenTest-Checklist/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29265466,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-09T04:11:57.159Z","status":"ssl_error","status_checked_at":"2026-02-09T04:11:56.117Z","response_time":56,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-22T15:23:15.409Z","updated_at":"2026-02-09T12:36:23.056Z","avatar_url":"https://github.com/CyberSecurityUP.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Web-PenTest-Checklist\n\n## Cookie Settings\n\n- Insecure transmission: Ensure cookies are sent only over HTTPS connections, to prevent interception by attackers. Set the \"Secure\" attribute for all cookies.\n\n- Missing HttpOnly attribute: Set the \"HttpOnly\" attribute to ensure cookies are inaccessible to client-side scripts, reducing the risk of cross-site scripting (XSS) attacks.\n\n- Missing SameSite attribute: Set the \"SameSite\" attribute to \"Strict\" or \"Lax\" to prevent cross-site request forgery (CSRF) attacks by ensuring cookies are only sent with requests originating from the same domain.\n\n- Excessive cookie lifetime: Limit the duration of cookie validity by setting the \"Expires\" or \"Max-Age\" attribute. Long-lived cookies pose a greater risk if they are compromised.\n\n- Weak encryption: Use strong encryption algorithms and up-to-date cryptographic libraries to protect sensitive information stored in cookies.\n\n- Insufficiently random session IDs: Ensure session IDs are generated using a strong source of randomness, to prevent session hijacking and guessing attacks.\n\n- Overly permissive cookie domain and path: Limit the scope of cookies by setting the \"Domain\" and \"Path\" attributes to specific subdomains or directories, reducing the risk of unauthorized access.\n\n- Storing sensitive information in cookies: Avoid storing sensitive information, such as passwords, API keys, or personally identifiable information (PII) in cookies. Instead, store them server-side and use session IDs to reference the data.\n\n- Unprotected cookie values: Ensure that cookie values are hashed, encrypted, or signed to protect them from being tampered with by attackers.\n\n- Inadequate monitoring and logging: Implement a proper monitoring and logging system to track cookie usage, to help detect and respond to potential security incidents.\n\n## SSRF\n\n- Test user-controlled URLs: Identify user-controlled URL inputs and test them with external URLs to see if the server fetches or processes them.\n\n- Test internal IP addresses: Attempt to access internal IP addresses (e.g., 127.0.0.1 or 10.0.0.0/8) or services through user-controlled inputs to check if the server processes them.\n\n- Use URL schemas: Test various URL schemas, such as file://, ftp://, or gopher://, to bypass input validation or access internal resources.\n\n- Test domain resolution: Test if your server resolves domain names to internal IP addresses by using a domain that points to an internal IP address.\n\n- Test URL redirection: Test if the server follows redirects by supplying a URL that redirects to an internal or external resource.\n\n- Test with different HTTP methods: Test SSRF vulnerabilities with various HTTP methods, such as GET, POST, PUT, DELETE, or HEAD.\n\n- Test with malformed URLs: Test with malformed URLs that may bypass input validation, such as using @ to separate credentials or adding extra slashes.\n\n- Test for open ports: Attempt to access open ports on the server or internal network by specifying the target IP and port in the URL.\n\n- Test for Out-of-Band (OOB) data exfiltration: Test if the server can send data to an external domain you control, which may indicate an SSRF vulnerability.\n\n- Test for cloud service metadata: If your site is hosted on a cloud provider, test if the server can access cloud service metadata endpoints, which may expose sensitive information.\n\n- Test with time-based techniques: Use time-based techniques, such as delays or timeouts, to confirm SSRF vulnerabilities when the server response doesn't reveal the fetched content.\n\n- Test for protocol smuggling: Test for protocol smuggling, such as using http:// within an https:// URL, to bypass input validation or access internal resources.\n\n- Test for bypassing URL filtering: Attempt to bypass URL filtering using techniques like URL encoding, double encoding, or mixed case encoding.\n\n- Use web application scanners: Use automated web application scanners, such as Burp Suite or OWASP ZAP, to identify potential SSRF vulnerabilities.\n\n- Test with IPv6 addresses: Test for SSRF vulnerabilities using IPv6 addresses to bypass input validation or access internal resources.\n\n## WAF Testing\n\n- Test with OWASP Top Ten attacks: Test for the most common web application vulnerabilities, such as SQLi, XSS, CSRF, and RCE.\n\n- Use WAF testing tools: Utilize tools like Wafw00f, Nmap, or WAPT to identify and test your WAF's capabilities.\n\n- Test for HTTP methods: Test different HTTP methods (GET, POST, PUT, DELETE, etc.) to check if your WAF is properly filtering and blocking malicious requests.\n\n- Test for HTTP protocol violations: Send requests that violate the HTTP protocol to see if your WAF can detect and block them.\n\n- Test with malformed requests: Send malformed requests with invalid or unexpected characters, encoding, or headers to test if your WAF can detect and block them.\n\n- Test for evasion techniques: Test various evasion techniques, such as URL encoding, double encoding, or using mixed case, to bypass input filters and WAF rules.\n\n- Test for IP and user agent blocking: Test if your WAF can block specific IPs or user agents, and check for bypass techniques using proxies or fake user agents.\n\n- Test for rate limiting: Test if your WAF can enforce rate limiting and block requests that exceed the allowed rate.\n\n- Test for cookie security: Test if your WAF can detect and block cookie manipulation, such as injecting malicious code or altering session cookies.\n\n- Test for file upload vulnerabilities: Test if your WAF can detect and block malicious file uploads, such as uploading web shells or malware.\n\n- Test for known attack signatures: Test your WAF's ability to detect and block known attack signatures using tools like Burp Suite or OWASP ZAP.\n\n- Test custom WAF rules: Test custom WAF rules and configurations to ensure they properly block malicious requests.\n\n- Test for false positives: Ensure your WAF doesn't block legitimate traffic by testing with common requests and inputs that may trigger false positives.\n\n- Test for false negatives: Ensure your WAF doesn't allow malicious traffic by testing with known attack vectors that should trigger blocking.\n\n- Test for SSL/TLS vulnerabilities: Test if your WAF can detect and block SSL/TLS vulnerabilities, such as POODLE or Heartbleed.\n\n- Test for XML vulnerabilities: Test if your WAF can detect and block XML-based attacks, such as XXE or XEE.\n\n- Test for header injection: Test if your WAF can detect and block header injection attacks, such as CRLF injection or response splitting.\n\n- Test for path traversal attacks: Test if your WAF can detect and block path traversal attacks, such as directory traversal or file inclusion.\n\n- Test for application-layer DDoS attacks: Test if your WAF can detect and block application-layer DDoS attacks, such as Slowloris or RUDY.\n\n- Perform continuous testing and monitoring: Regularly test your WAF's effectiveness and monitor its logs to detect and block new attack vectors and emerging threats.\n\n## Header Vulnerability\n\n- Missing Strict-Transport-Security (HSTS) header: Enables HTTPS-only communication, preventing man-in-the-middle attacks.\n\n- Missing X-Content-Type-Options header: Disables MIME type sniffing, reducing the risk of attacks using MIME confusion.\n\n- Missing X-Frame-Options header: Prevents clickjacking attacks by disallowing or limiting the site from being embedded within frames.\n\n- Missing Content-Security-Policy (CSP) header: Defines allowed sources of content, reducing the risk of cross-site scripting (XSS) and content injection attacks.\n\n- Missing X-XSS-Protection header: Activates built-in browser protection against cross-site scripting (XSS) attacks.\n\n- Missing Referrer-Policy header: Controls the information sent in the Referer header, protecting user privacy and reducing the risk of information leakage.\n\n- Missing Feature-Policy header: Restricts the use of certain browser features and APIs, improving security and privacy.\n\n- Insecure CORS (Cross-Origin Resource Sharing) settings: Allows unauthorized domains to access resources, increasing the risk of cross-site request forgery (CSRF) and data leakage.\n\n- Missing Expect-CT header: Enforces Certificate Transparency, reducing the risk of misissued SSL/TLS certificates.\n\n- Missing Permissions-Policy header: Defines which browser features are allowed or denied, enhancing user privacy and security.\n\n- Weak or missing Public-Key-Pins (HPKP) header: Ensures the use of specific cryptographic public keys, reducing the risk of man-in-the-middle attacks using rogue certificates.\n\n- Missing X-Download-Options header: Prevents file download prompts from being displayed, reducing the risk of drive-by download attacks.\n\n- Missing X-Permitted-Cross-Domain-Policies header: Restricts the loading of content from other domains, reducing the risk of data theft.\n\n- Missing X-DNS-Prefetch-Control header: Controls DNS prefetching, potentially improving user privacy.\n\n- Inadequate Cache-Control settings: Insecure caching settings can expose sensitive information or allow unauthorized access to content.\n\n- Missing X-Content-Duration header: Helps prevent unauthorized media access by specifying the duration of media files.\n\n- Missing Access-Control-Allow-Origin header: Improper configuration can result in unauthorized cross-origin resource sharing.\n\n- Missing X-WebKit-CSP header: This older header is used by some legacy browsers for content security policy enforcement.\n\n- Missing X-Content-Security-Policy header: Similar to X-WebKit-CSP, this older header is used by some legacy browsers for content security policy enforcement.\n\n- Missing X-XContent-Type-Options header: Disables MIME sniffing on older browsers, reducing the risk of MIME confusion attacks.\n\n- Insecure ETag settings: Weak ETag settings can cause caching issues, potentially exposing sensitive information.\n\n- Missing or weak Content-Encoding header: Properly configuring this header helps protect against attacks that rely on manipulating content encoding.\n\n- Missing or weak Content-Language header: Properly configuring this header helps protect against attacks that rely on manipulating content language.\n\n- Missing or weak Last-Modified header: Properly configuring this header helps protect against attacks that rely on manipulating content modification timestamps.\n\n- Insecure or missing Cookie headers: As mentioned in the previous answer, insecure cookie settings can lead to various security vulnerabilities.\n\n## SQL Injection\n\n- Single quote test: Inject a single quote ' into input fields and observe if it generates an error or unexpected behavior, which might indicate a potential SQLi vulnerability.\n\n- Tautologies: Inject tautologies like 1=1 or a=a into input fields or URL parameters to test for boolean-based SQLi.\n\n- Union-based SQLi: Use the UNION operator to combine the results of two or more SELECT statements and extract data from other tables.\n\n- Error-based SQLi: Inject incorrect syntax or invalid input to trigger error messages that reveal database structure or sensitive information.\n\n- Time-based SQLi: Inject time-delaying functions like SLEEP() or WAITFOR DELAY to test for time-based SQLi vulnerabilities.\n\n- Out-of-band (OOB) SQLi: Test for OOB SQLi by injecting payloads that cause the database to make external requests, such as DNS lookups or HTTP requests, to exfiltrate data.\n\n- Double encoding: Test with double-encoded payloads to bypass filters that only decode input once. Example: %253Cscript%253Ealert(1)%253C%252Fscript%253E.\n\n- Use SQL comment characters: Inject SQL comment characters (--, /*, */) to bypass input filters or terminate SQL statements.\n\n- Manipulate query logic: Inject logical operators such as AND or OR to manipulate the query's logic and bypass access controls.\n\n- Test with different SQL dialects: Use payloads specific to different SQL dialects (e.g., MySQL, PostgreSQL, Oracle, or MSSQL) to identify database-specific vulnerabilities.\n\n- Test various HTTP methods: Test for SQLi vulnerabilities using different HTTP methods, such as POST, PUT, or PATCH, with SQLi payloads.\n\n- Test with URL-encoded or base64-encoded parameters: Try URL-encoded or base64-encoded parameters to bypass input validation or access control checks.\n\n- Test various content types: Test for SQLi vulnerabilities in different content types that support user input, such as JSON, XML, or URL-encoded form data.\n\n- Manipulate cookies: Inject SQL payloads into cookies to test if the application processes them in an unsafe manner.\n\n- Use web application scanners: Use automated web application scanners, such as Burp Suite or OWASP ZAP, to identify potential SQLi vulnerabilities.\n\n## TLS Vulnerability\n\n- Weak or outdated SSL/TLS protocols: Ensure your site only supports secure and up-to-date protocols like TLS 1.2 and TLS 1.3, and disable insecure ones like SSL 2.0, SSL 3.0, and TLS 1.0.\n\n- Insecure cipher suites: Disable weak cipher suites and use strong ones, such as those based on AES-GCM, ChaCha20-Poly1305, or ECDHE (Elliptic Curve Diffie-Hellman).\n\n- Vulnerability to known attacks: Protect your site from known TLS attacks, such as POODLE, BEAST, CRIME, BREACH, or Heartbleed, by applying security patches and following best practices.\n\n- Inadequate certificate management: Use a valid, trusted, and up-to-date SSL/TLS certificate from a reputable Certificate Authority (CA). Regularly check for certificate expiration and renewals.\n\n- Insufficient certificate chain validation: Ensure proper validation of the certificate chain to prevent man-in-the-middle attacks using rogue or misissued certificates.\n\n- Weak or missing public key pinning: Implement HTTP Public Key Pinning (HPKP) or Certificate Transparency to enforce the use of specific public keys and reduce the risk of man-in-the-middle attacks.\n\n- Mixed content: Ensure that all content, including images, stylesheets, and scripts, are served over HTTPS to prevent mixed content warnings and potential attacks.\n\n- Insecure renegotiation: Disable insecure client-initiated renegotiation to protect your site from man-in-the-middle attacks exploiting this vulnerability.\n\n- Insufficient forward secrecy: Use cipher suites that support forward secrecy, such as ECDHE or DHE, to protect past communications from being decrypted even if the server's private key is compromised.\n\n- Lack of OCSP stapling: Implement OCSP (Online Certificate Status Protocol) stapling to reduce the latency of SSL/TLS handshakes and provide real-time certificate revocation information.\n\n## File Upload\n\n- File size limit: Verify that there is an appropriate file size limit in place to prevent large file uploads that could potentially exhaust server resources.\n\n- File type restrictions: Ensure that only allowed file types can be uploaded, and test with disallowed file types to confirm the restrictions are working.\n\n- MIME type validation: Check that the MIME type of uploaded files is being validated and that the system rejects files with incorrect MIME types.\n\n- Filename validation: Test that the system filters and sanitizes filenames to avoid malicious filenames (e.g., \"../\", \".htaccess\") that could lead to security vulnerabilities.\n\n- Malware scanning: Scan uploaded files for malware or viruses using an up-to-date antivirus solution.\n\n- Duplicate file names: Test how the system handles duplicate file names, ensuring that it doesn't overwrite existing files or create security vulnerabilities.\n\n- Upload directory: Verify that the upload directory is secured and not accessible for unauthorized users.\n\n- Permissions: Ensure that proper file and folder permissions are set to prevent unauthorized access, modification, or deletion of uploaded files.\n\n- User authentication: Test if file uploads require proper user authentication and that unauthorized users cannot upload files.\n\n- Image validation: If uploading images, test for potential vulnerabilities related to image processing libraries (e.g., buffer overflows, code injection).\n\n- File content validation: Ensure that the content of the files is validated and doesn't contain malicious code or scripts.\n\n- Maximum file uploads: Test the maximum number of simultaneous file uploads to ensure the system can handle the load without crashing or compromising security.\n\n- Timeouts: Test the system for handling long uploads and confirm that it has appropriate timeouts in place.\n\n- Rate limiting: Verify that the system has rate limiting in place to prevent abuse and denial of service (DoS) attacks.\n\n- Error handling: Test the system's error handling capabilities to ensure that it doesn't leak sensitive information or create security vulnerabilities.\n\n- Cross-site scripting (XSS): Test for potential XSS vulnerabilities related to file uploads, such as the inclusion of malicious scripts within file metadata.\n\n- Path traversal: Test for path traversal vulnerabilities by attempting to upload files with directory traversal characters (e.g., \"../\") in the file name.\n\n- SQL injection: Test for potential SQL injection vulnerabilities related to file uploads, such as manipulating metadata to include malicious SQL queries.\n\n- Access control: Verify that proper access controls are in place for viewing, editing, or deleting uploaded files.\n\n- Logging and monitoring: Ensure that the system logs and monitors all file upload activities for potential security threats and suspicious behavior.\n\n## XSS\n\n- Basic payload injection: Inject simple script tags or HTML tags with JavaScript event handlers into input fields or query parameters. Example: \u003cscript\u003ealert(1)\u003c/script\u003e or \u003cimg src=x onerror=alert(1)\u003e.\n\n- URL encoding: Use URL-encoded payloads to bypass input filters that may block certain characters. Example: %3Cscript%3Ealert(1)%3C%2Fscript%3E.\n\n- Hex encoding: Test with hex-encoded payloads to bypass filters that block specific characters. Example: \u003cscr\\x69pt\u003ealert(1)\u003c/scr\\x69pt\u003e.\n\n- Case variation: Try different letter casing to bypass case-sensitive filters. Example: \u003cScRiPt\u003ealert(1)\u003c/ScRiPt\u003e.\n\n- HTML entity encoding: Inject payloads with HTML entities to evade filters that remove or escape specific characters. Example: \u0026lt;script\u0026gt;alert(1)\u0026lt;/script\u0026gt;.\n\n- Null byte injection: Use null bytes to break out of input restrictions or bypass filters. Example: \u003cscr%00ipt\u003ealert(1)\u003c/scr%00ipt\u003e.\n\n- Double encoding: Test with double-encoded payloads to bypass filters that only decode input once. Example: %253Cscript%253Ealert(1)%253C%252Fscript%253E.\n\n- Attribute injection: Attempt to inject payloads within existing HTML tags by closing the current attribute and adding a new one with malicious JavaScript. Example: \"\u003e\u003cimg src=x onerror=alert(1)\u003e.\n\n- JavaScript event handlers: Inject JavaScript event handlers, such as onmouseover, onfocus, or onclick, into various HTML elements to trigger the payload.\n\n- Malformed tags: Test with malformed tags to bypass filters that look for well-formed HTML. Example: \u003cscrip\u003cscript\u003et\u003ealert(1)\u003c/scrip\u003c/script\u003et\u003e.\n\n- Using different contexts: Test payloads in various contexts, such as HTML comments, inline JavaScript, or CSS, to bypass context-specific filters.\n\n- Data URI: Inject data URI payloads to bypass certain input filters. Example: \u003ciframe src=\"data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==\"\u003e\u003c/iframe\u003e.\n\n- SVG payloads: Use Scalable Vector Graphics (SVG) payloads to execute JavaScript in a different context. Example: \u003csvg onload=\"alert(1)\"\u003e\u003c/svg\u003e.\n\n- Breaking out of JavaScript: Inject payloads that break out of existing JavaScript code and execute malicious scripts.\n\n- Testing error pages: Check if error pages, such as 404 or 500, reflect user input without proper encoding, as these can be used for reflected XSS attacks.\n\n## XXE\n\n- Basic external entity: Inject a basic external entity reference to test if the parser resolves it\n\n- External parameter entity: Inject an external parameter entity to bypass input filters. \n\n- Blind XXE (OOB technique): Use Out-of-Band (OOB) techniques to exfiltrate data if the response doesn't display the content of the external entity.\n\n- File inclusion: Attempt to include local or remote files using the SYSTEM identifier to test for arbitrary file inclusion.\n\n- Internal entity expansion: Inject an internal entity with a large number of nested entities to test for a Billion Laughs attack (a type of denial-of-service attack).\n\n- Recursive entity references: Test for recursive entity expansion to identify potential denial-of-service (DoS) vulnerabilities.\n\n- XML bomb: Inject a large XML file with deeply nested elements to test for XML bomb vulnerabilities, which can lead to DoS attacks.\n\n- Error-based XXE: Inject malformed XML with external entity references to trigger errors that reveal sensitive information.\n\n- XML encoding: Try different XML encodings (e.g., UTF-16, UTF-32) to bypass input filters that block specific characters.\n\n- Use CDATA sections: Inject external entity references inside CDATA sections to bypass input filters that remove or escape specific characters.\n\n- Custom entities: Create custom entities with external references to test if the XML parser resolves them.\n\n- Test various content types: Test for XXE vulnerabilities in different content types that support XML, such as SOAP, XHTML, SVG, or RSS.\n\n- Test XML-based file formats: Test for XXE vulnerabilities in XML-based file formats, such as Office Open XML (.docx, .pptx, .xlsx) or OpenDocument (.odt, .ods, .odp).\n\n- Test different HTTP methods: Test for XXE vulnerabilities using different HTTP methods, such as POST, PUT, or PATCH, with XML payloads.\n\n- Test XML-based APIs: Test for XXE vulnerabilities in XML-based APIs, such as XML-RPC or SOAP-based web services.\n\n## IDOR\n\n- Sequential IDs: Analyze sequential numeric IDs or predictable identifiers in URLs, API endpoints, or hidden form fields, and try modifying them to access unauthorized resources.\n\n- User-specific data: Ensure proper authorization checks are in place for user-specific data, such as profiles, orders, or messages, by attempting to access another user's data using your authenticated session.\n\n- Enumerate identifiers: Create multiple accounts with different roles (e.g., admin, user) and compare the object identifiers to identify patterns or correlations.\n\n- Test file uploads: Test file upload functionality and attempt to access uploaded files by guessing or modifying their filenames.\n\n- Test API endpoints: Analyze API endpoints for exposed object references and attempt to access unauthorized resources by modifying request parameters.\n\n- Test hidden form fields: Examine hidden form fields for object references and modify their values to access unauthorized resources.\n\n- Test JSON or XML responses: Analyze JSON or XML responses for exposed object references and attempt to access unauthorized resources by modifying request parameters.\n\n- Test related features: Test related features or modules, such as password reset or email validation, for IDOR vulnerabilities by modifying request parameters.\n\n- Test with different roles: Create accounts with different roles (e.g., admin, user, guest) and attempt to access unauthorized resources using different user sessions.\n\n- Test with unauthenticated sessions: Test if unauthenticated users can access resources by modifying object references in URLs or API endpoints.\n\n- Use web application scanners: Use automated web application scanners, such as Burp Suite or OWASP ZAP, to identify potential IDOR vulnerabilities.\n\n- Analyze access logs: Review server access logs for patterns indicating unauthorized access attempts.\n\n- Manipulate cookies: Manipulate cookies or session tokens to impersonate other users and attempt to access unauthorized resources.\n\n- Test request methods: Test for IDOR vulnerabilities using different HTTP request methods, such as GET, POST, PUT, DELETE, or PATCH.\n\n- Test with URL-encoded or base64-encoded parameters: Try URL-encoded or base64-encoded parameters to bypass input validation or access control checks.\n\n## Subdomain Takeover\n\n- Enumerate subdomains: Use tools like Sublist3r, Amass, or dnsrecon to discover subdomains associated with your main domain.\n\n- Analyze DNS records: Check DNS records (e.g., CNAME, A, AAAA, MX) for subdomains pointing to external services or expired domains.\n\n- Check HTTP responses: Examine HTTP responses for error messages or status codes that may indicate an unclaimed or expired external service.\n\n- Use online services: Utilize online services such as crt.sh or Censys to gather subdomain and certificate data for your main domain.\n\n- Test common third-party services: Check if subdomains are pointing to common third-party services, such as AWS S3, GitHub Pages, or Heroku, that are susceptible to subdomain takeover attacks.\n\n- Test for dangling CNAME records: Look for dangling CNAME records that point to external services that have been deleted or expired.\n\n- Monitor domain registration: Monitor domain registration information for expired domains that can be taken over.\n\n- Use subdomain takeover tools: Utilize tools like SubOver, Subjack, or tko-subs to automatically identify subdomain takeover vulnerabilities.\n\n- Check for misconfigured DNS settings: Examine DNS settings for misconfigurations that might lead to subdomain takeover vulnerabilities.\n\n- Test for wildcard DNS records: Check for wildcard DNS records that might expose subdomains to takeover attacks.\n\n- Check for abandoned subdomains: Look for abandoned subdomains that still point to unused external services.\n\n- Test for improper redirects: Check if subdomains are improperly redirecting traffic to external services that can be taken over.\n\n- Monitor domain ownership changes: Monitor domain ownership changes for potential takeover opportunities.\n\n- Collaborate with third-party service providers: Work with third-party service providers to ensure proper domain configuration and prevent subdomain takeover.\n\n- Regularly audit subdomain configurations: Periodically review your subdomain configurations to identify and mitigate potential subdomain takeover risks.\n\n## Wordpress CMS\n\n- Keep WordPress updated: Regularly update the WordPress core, plugins, and themes to protect against known vulnerabilities.\n\n- Test for weak passwords: Ensure strong passwords are used for all user accounts, especially for administrator accounts.\n\n- Check for user enumeration: Test if usernames can be enumerated through the WordPress author archives or other means, and disable user enumeration if possible.\n\n- Test for default admin username: Ensure the default \"admin\" username is not used, and replace it with a custom username.\n\n- Limit login attempts: Test if login attempts are limited to prevent brute-force attacks, and install a plugin like Login LockDown or Wordfence to enable this functionality if necessary.\n\n- Test for insecure file permissions: Check the permissions of your WordPress files and folders to ensure they are secure and cannot be accessed by unauthorized users.\n\n- Test for XML-RPC vulnerabilities: Test for vulnerabilities related to the XML-RPC feature, such as DDoS or brute-force attacks, and disable it if not needed.\n\n- Test for SQL injection vulnerabilities: Test your WordPress site for SQL injection vulnerabilities by injecting SQL payloads into input fields or URL parameters.\n\n- Test for Cross-Site Scripting (XSS) vulnerabilities: Test your WordPress site for XSS vulnerabilities by injecting JavaScript payloads into input fields or URL parameters.\n\n- Test for Cross-Site Request Forgery (CSRF) vulnerabilities: Test your WordPress site for CSRF vulnerabilities by attempting to perform actions without a valid CSRF token or by using another user's authenticated session.\n\n- Test for vulnerable plugins: Check for known vulnerabilities in your installed plugins using tools like WPScan or by regularly monitoring vulnerability databases.\n\n- Test for vulnerable themes: Check for known vulnerabilities in your installed themes using tools like WPScan or by regularly monitoring vulnerability databases.\n\n- Test for insecure configurations: Check your WordPress configuration (wp-config.php) for insecure settings, such as displaying errors, and secure it by disabling features like error reporting or file editing.\n\n- Check for security best practices: Ensure your site follows WordPress security best practices, such as using HTTPS, disabling directory browsing, or setting secure HTTP headers.\n\n- Use a security plugin: Install a comprehensive security plugin like Wordfence, iThemes Security, or Sucuri to monitor and protect your site from various threats.\n\n## https://www.linkedin.com/in/joas-antonio-dos-santos\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcybersecurityup%2Fweb-pentest-checklist","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcybersecurityup%2Fweb-pentest-checklist","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcybersecurityup%2Fweb-pentest-checklist/lists"}