Skip to content

whitelist: add getbags.app + *.getbags.app (BAGS — Solana Merchant of Record) #1817

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
VedantAnand17 wants to merge 1 commit into
base: master
Choose a base branch
from
Open

whitelist: add getbags.app + *.getbags.app (BAGS — Solana Merchant of Record) #1817

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion whitelist.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,4 +30,6 @@
- url: "*.tistory.com"
- url: "*.surge.sh"
- url: revoke.cash
- url: nftplus.io
- url: nftplus.io
- url: getbags.app
- url: "*.getbags.app"
Comment on lines +34 to +35
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot May 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical | 🏗️ Heavy lift

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Description: Verify domain ownership claims and check for existing verification documentation

echo "=== Checking for ownership verification documentation ==="
# Search for any verification docs, security reviews, or approval trails
rg -i "getbags\.app|verification|ownership|approval|security.*review" --type md --type txt -C 3

echo -e "\n=== Checking for whitelist addition process documentation ==="
# Look for documented whitelist addition process
fd -e md -e txt | xargs rg -l "whitelist.*process|whitelist.*criteria|whitelist.*approval" | head -5

echo -e "\n=== Checking git log for PR approval/review ==="
# Check recent commits for review/approval patterns
git log --oneline --grep="review\|approve\|verify" -10

echo -e "\n=== Checking for security policy documentation ==="
fd SECURITY.md README.md CONTRIBUTING.md | head -5

Repository: phantom/blocklist

Length of output: 530

🌐 Web query:

What are the current best practices for domain age requirements in crypto wallet whitelists?

💡 Result:

In the context of crypto wallet whitelisting, domain age is not considered a primary or standalone security control [1][2]. While it can serve as a supplemental signal for risk assessment, relying on it as a foundation for security is discouraged due to its limitations in modern threat landscapes [1][2]. Current best practices for securing crypto wallet whitelists focus on robust identity verification, multi-party governance, and behavioral analysis rather than domain age [3][4][5]. Key Security Practices for Wallet Whitelists: 1. Identity and Control Verification: Before an address is added to a whitelist, the owner should complete Know Your Customer (KYC) checks [3][5]. Additionally, the user should prove control over the wallet, typically by signing a cryptographic message [3][4][5]. 2. Multi-Approver Governance: To prevent unauthorized changes, whitelist modifications should require approval from multiple authorized individuals [3][4]. This mitigates the risk of a single compromised account or malicious insider modifying destination addresses [3][4]. 3. Activation Delays: Implementing a mandatory waiting period (e.g., 24 hours) after a new address is added to a whitelist provides a critical window to detect and reverse unauthorized additions [5]. 4. Comprehensive Risk Screening: Addresses should be screened against sanctions lists and monitored for links to known fraudulent activity or high-risk entities [3][4][5]. 5. Limitations of Domain Age: While some automated tools use domain age to flag potentially suspicious sites or services, it is an imperfect metric [1][2]. Attackers frequently bypass age-based filters by using aged domains purchased on secondary markets, compromising legitimate sites, or aging domains before launching campaigns [2]. Consequently, security strategies should prioritize comprehensive threat intelligence, behavioral analysis, and strict access controls over domain age thresholds [1][2]. In summary, while domain age may provide limited supplemental value in automated filtering, it should not be relied upon as a primary security mechanism for crypto wallet whitelisting [1][2]. Instead, organizations should implement layered defenses centered on identity verification, multi-party approval, and continuous monitoring [3][4][5].

Citations:

Document verification process and security approval before merging.

Adding domains to this whitelist bypasses security checks in Phantom wallet. While the commit references "BAGS — Solana Merchant of Record," the following documentation gaps must be resolved:

  1. No verification documentation: Neither ownership verification (DNS TXT, /.well-known, wallet signatures) nor any approval evidence exists in the repository or PR.

  2. Missing approval from security team: No documented approval from security reviewers is included.

  3. Unverifiable security claims: Claims about bounded on-chain behavior cannot be verified from configuration changes and require audit documentation.

  4. Wildcard scope: The pattern *.getbags.app whitelists all subdomains, which should be justified or narrowed if possible.

Required before merge: Document completed ownership verification, explicit security team approval, and security audit results validating the dApp's on-chain behavior.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@whitelist.yaml` around lines 34 - 35, Add required verification and approval
artifacts for the new whitelist entries in whitelist.yaml: attach documented
ownership verification (e.g., DNS TXT, /.well-known proof, or signed wallet
message) and reference the exact proofs next to the url: getbags.app and url:
"*.getbags.app" entries, record an explicit security team approval note
(reviewer name, date, and checklist) and link any security audit or
bounded-on-chain-behavior report; if wildcard scope is not justified, narrow or
remove the "*.getbags.app" entry and include rationale for any remaining
wildcard usage in the same documentation block.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot May 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Wildcard subdomain pattern significantly amplifies security risk.

The *.getbags.app wildcard pattern allows ALL subdomains to bypass security checks, which creates multiple risk vectors:

  1. Expanded attack surface: If DNS or hosting is compromised, attackers can create arbitrary malicious subdomains that inherit whitelist status.

  2. No subdomain isolation: Different subdomains may serve different purposes with varying security levels (e.g., staging vs production, admin vs public), but all receive the same trust level.

  3. Difficult remediation: Revoking access requires removing the entire wildcard entry, potentially disrupting legitimate services.

Comparison with existing wildcards: Other wildcards in this file (e.g., *.github.io, *.netlify.app, *.vercel.app) are for established hosting platforms with their own security controls and cannot be arbitrarily manipulated by a single entity.

Recommendation:

  • Preferred: Limit to specific subdomains that require whitelisting (e.g., checkout.getbags.app, pay.getbags.app)
  • Alternative: Start with apex domain only (getbags.app) and expand based on demonstrated need and security track record
🔒 Suggested change to use specific subdomain(s)

Based on PR objectives mentioning "production checkout dApp at https://www.getbags.app/pay/*", consider:

  - url: nftplus.io
  - url: getbags.app
- - url: "*.getbags.app"

Or if subdomains are required, specify them explicitly:

  - url: nftplus.io
  - url: getbags.app
- - url: "*.getbags.app"
+ - url: pay.getbags.app
+ - url: checkout.getbags.app
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
- url: "*.getbags.app"
- url: getbags.app
Suggested change
- url: "*.getbags.app"
- url: getbags.app
- url: pay.getbags.app
- url: checkout.getbags.app
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@whitelist.yaml` at line 35, The wildcard entry "*.getbags.app" in the
whitelist.yaml is too permissive; remove that wildcard line and replace it with
explicit allowed hosts such as the apex domain "getbags.app" and only the
specific subdomains needed for the PR (e.g., "www.getbags.app" and the exact
subdomain(s) serving the checkout/pay flow like "pay.getbags.app" or
"checkout.getbags.app"); ensure the whitelist contains only these explicit host
entries and not a wildcard to limit attack surface and allow granular
revocation.

Loading