1. WAF Bypass
   1. Direct Server Access
      1. Searh on shodan or Censys for any Domain/Sub that have WAF and see by wafw00f tool If this IP dosen't Implement WAF.
2. Content Spoofing
   1. Broken Link Hijacking
      1. Use this extension to find broken links.
   2. Email HTML Injection
      1. I was able to achieve this by injecting the following code into all input fields I encountered: <a href="https://evil.com">Click Here to get $100</a>. I then triggered an action on the website that resulted in an email being sent to me. To my surprise, I noticed that my name was rendered as HTML content in the email.
   3. Basic SSTI
      1. It just non-high Impact SSTI to my knowledge.
3. Sensitive Data Exposure
   1. EXIF Geolocation Data Not Stripped From Uploaded Images
   2. Via localStorage/sessionStorage
      1. After logging out or logging in into the application see any sensitive information on the local storge
   3. Token Leakage via Referer
      1. Try requesting the reset password URL for example in the Browser and after that try to visit the main website while intercepting to see if there's the token is leaked via referer header
   4. Password Reset Token Sent Over HTTP
      1. Check when initiating a Password Reset URL if it sends over HTTP non HTTPs
   5. Sensitive Token in URL
      1. See if there's any sensitive token in the URL such as the session token or something
   6. Pay-Per-Use Abuse
      1. Search for any API Token or Any Sensitive Endpoints and try to making the PoC by making a 200 OK request to these things
4. Weak Password Reset Implementation
   1. Token is Not Invalidated After Use
      1. In a secure password reset process, the token provided for resetting the password should be invalidated immediately after it is successfully used. This one-time use property ensures that the token cannot be reused by an attacker to repeatedly reset the password and gain unauthorized access to the account.
      2. To fix this issue, the application should be modified to invalidate the password reset token as soon as it is used to reset the password.
5. Username/Email Enumeration
6. Open Redirect
7. Server-Side Request Forgery (SSRF)
   1. External
8. Cross-Site Scripting (XSS)
   1. Data URI
      1. Use the XSS Data URI Payload from here!
   2. Referer
      1. Referer: http://www.google.com/search?hl=en&q=c5obc'+alert(1)+'p7yd5
9. Misconfigured DNS
   1. Zone Transfer
      1. Just use this website for testing the targeted domain.
10. Mail Server Misconfiguration
    1. Email Spoofing - Missing DMARC
       1. Use this website for check the domain is vulnerable?
       2. Use this website for the PoC
11. Lack of Password Confirmation
    1. Delete Account
       1. As simple it is, Just see if there's any confirmation when deleting your Account
12. No Rate Limiting on Form
    1. Registration
    2. Login
    3. Email-Triggering
    4. SMS-Triggering
13. Broken Authentication and Session Management
    1. Failure to Invalidate Session on Logout
       1. Capture a request while authenticated using Burp. Then, log out from the application using the browser. Attempt to resend the request using Burp and observe if it is successful or not.
    2. Failure to Invalidate Session on Reset Password
    3. Cleartext Transmission of Session Token
       1. Observe that the session is send as PlainText without existance of `secure` flag curl http://example.com/path/to/resource
    4. Registration over HTTP
    5. Login over HTTP
14. No Password Policy
    1. Just type 1 or 123 for the password and observe that you can register successfully.
15. 2FA Implementation
    1. 2FA Secret Remains Obtainable After 2FA is Enabled
       1. In a secure 2FA implementation, the 2FA secret should not be accessible or retrievable after it has been used to set up 2FA. It's usually shown only once during the setup process and should not be available for retrieval or viewing later.
       2. To fix this bug, the application should ensure that the 2FA secret is only shown during the initial setup and is not retrievable afterward. Additionally, the URL where the secret is accessible should be protected to prevent unauthorized access. This helps ensure the security of user accounts that have 2FA enabled.
    2. 2FA Secret Cannot be Rotated
       1. In a secure 2FA implementation, users should have the option to change their 2FA secret if they suspect it has been compromised or for periodic security best practices.
       2. To address this issue, the application should implement a feature that allows users to change or rotate their 2FA secret. This feature should be easily accessible within the account settings, and the old secret should be invalidated when a new one is generated to ensure security.
16. CAPTCHA Bypass
    1. Use this tricks to bypass CAPTCHA
17. Lack of Security Headers
    1. Missing Secure or HTTPOnly Cookie Flag
       1. Check if the session token is missing the HTTPonly falg and be sure if it is really the session token :)
    2. Cache-Control for a Sensitive Page
       1. Open any sensitive-response page on your browser and capture it request in burp. Observe that there's not cache-control headers in the response or it don't expire. Try send this request in Burp after closing your browser and observe that you can see the Sensitive Information.
18. 1. Utilize the Bugcrowd email alias to generate emails. 2. Employ Intruder to expedite the process of repeating the requests. 3. Refer to HackTricks notes for bypassing rate limits.