Dripster Backend Pentesting
Zealynx conducted a 10-day penetration test of the Dripster backend (NestJS / Prisma API at bloom-art/api), focusing on authentication, authorization, business logic, input validation, rate limiting, infrastructure, and Polymarket integration. The assessment surfaced 21 issues: 1 High, 4 Medium, 11 Low, and 5 Informational. 13 were fixed during the engagement window itself; 8 were acknowledged with detailed rationale (route disablement on dead surfaces, intended public API surfaces, test fixtures with no live secret material, or threat models superseded by the Polymarket V2 migration).
Scope
11 filesFindings
click any row for the full write-upKey Findings
- State-changing operation via unauthenticated GET (
/lending/referral-code/:walletAddress). A GET route auto-createdReferralCoderows for any wallet address, violating HTTP GET safety and enabling unauthenticated bulk pre-seeding of codes for arbitrary addresses. - API key exposed in WebSocket query parameters. Both authenticated WebSocket gateways accepted the partner API key via a
?apiKey=handshake query string, leakingdm_live_skey_...credentials into access logs, reverse-proxy logs, and browser history. Public partner integration docs actively recommended the leaking form. - Cache clear endpoint accepts arbitrary prefix without validation.
DELETE /admin/v1/cache/:cachePrefixforwarded an attacker-controlled URL path parameter into a RedisSCAN MATCH → UNLINKloop, allowing a compromised admin key to wipe security-critical prefixes such asliquidationExecution,settlementExecution, andevmEventStreamDedup, driving duplicate liquidations and on-chain event reprocessing. - Telegram webhook controller lacks signature verification. The webhook controller is currently disabled by a hardcoded boolean, but when enabled it would accept arbitrary POST requests without any cryptographic verification of the request origin. Combined with an attacker-controlled
update_idvalue, the anti-replay store can be bypassed entirely. - Static salt for API key hashing. Every partner API key was hashed with a hardcoded checked-in salt, so a database dump alone was sufficient to mount a parallel brute-force against every API key hash. Resolved during the engagement by moving the static secret out of the database and into a server-side pepper held in GCP Secret Manager.
Architectural Security Observations
- Hybrid on-chain / off-chain trust model. User collateral is locked on-chain while the backend holds the signing authority over every vault state transition, concentrating trust on the signing layer where hardware-backed protection (GCP KMS) is feasible.
- Six-layer authorization stack. API key (PBKDF2 + HMAC pepper), JWT with live DB revocation, role guards, object-level scoping, Prisma WHERE-clause ownership, and on-chain GCP KMS signature. Compromise of one layer does not collapse the rest.
- HSM-backed signing via GCP KMS. Polygon vault transactions are signed inside a FIPS 140-2 Level 3 HSM; the application sends a digest and receives a signature. Even full RCE in the Cloud Run container cannot exfiltrate the signing key, the most valuable secret never exists in software memory.
- Idempotent lifecycle state machine. A BullMQ queue plus Redis-backed
AntiReplayStore(SET NX) and aDistributedMutexServicemake every critical transition exactly-once at the operation level, with exponential-backoff retries and PagerDuty escalation on exhaustion. - Centralized secret management. All production secrets are referenced by GCP Secret Manager resource name only. IAM-gated access plus Cloud Audit Logs on every secret read mean credential exfiltration requires IAM compromise rather than a leaked file.
- Defense-in-depth with locatable weaknesses. Exceptional at the signing, async-state, and observability layers. Identified weaknesses are layer-specific and locally remediable (L-05 AES-CTR no auth tag; M-01 partner-admin object-level authorization), neither requires structural redesign.
Security Strengths Observed
- HSM-isolated signing authority. All on-chain Polygon transactions are signed via GCP KMS (ECDSA P-256k1, FIPS 140-2 Level 3 HSM). The signing key never enters application memory, and every signing operation lands in Cloud Audit Logs with caller, timestamp, and key version.
- Live JWT revocation.
CustomerJwtStrategyhits the database on every request to confirm the embeddedapiKeyIdis still valid. Revoking a partner key invalidates every outstanding customer JWT immediately, a property stateless JWT systems rarely offer. - Idempotent async state machine. Bull queue plus Redis-backed
AntiReplayStorepairs enforce exactly-once execution on financial operations. Double-settlement, double-liquidation, and replayed webhook events are blocked at the operation level even if they reach the queue multiple times. - Database-level ownership enforcement. Customer-facing position queries embed
walletAddressandpartnerIddirectly in the Prismawhereclause. Even if app-level authorization were bypassed, the database returns no rows for another user's position. - Strong webhook verification. QuickNode and Alchemy guards verify HMAC-SHA256 over the raw body via
timingSafeEqual; QuickNode binds nonce + timestamp + body for replay resistance. The timestamp-window gap (L-07) was the only finding on the surface. - Adaptive ML-driven risk engine. An ONNX two-stage classifier sets per-market max leverage from order-book microstructure (spread, depth, top-holder concentration, order-flow imbalance) plus correlated crypto moves and Synthesis cross-validation, replacing static rules with adaptive exposure limits.
Team & approval
Disclaimer
This audit is not an endorsement and does not constitute investment advice. Zealynx reviewed the codebase at the commits listed in section 02 over the engagement window. Findings are limited to issues identified within that scope and do not preclude the existence of other vulnerabilities. Subsequent code changes are not covered by this report unless the engagement is explicitly extended.

