AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 26 Monero

feat(shopinbit): add ShopInBit API client and service layer

Public commit record

What the developer wrote

Authored by sneurlax

62/100 · Adequate
feat(shopinbit): add ShopInBit API client and service layer
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
The short version

What changed, and why it matters

This commit adds a new feature: a Dart client and service layer for integrating with the ShopInBit API inside the Stack Wallet app. It lets the wallet talk to ShopInBit to create support tickets, upload messages/attachments, manage vouchers, handle car-research invoices, register push notifications, and verify webhooks. The code also adds generic HTTP PATCH and DELETE helpers. From the diff alone there is no clear security bug, but several design choices are worth reviewing: the service defaults to sandbox mode, customer keys are stored in the app's general preferences box, and attachment URLs can optionally put authentication tokens in query parameters where they may leak in logs or referrers.

Recommended action

Treat this as a feature addition requiring a security design review rather than an incident. Verify that useQueryAuth is only used where headers are truly impossible and that resulting URLs are not logged or cached. Move the customer key from the general Hive prefs box to encrypted/secure storage if the platform supports it. Confirm sandbox: true default is intentional and cannot reach production endpoints accidentally. Add request/connection timeouts to the new HTTP methods. Ensure external_api_keys.dart is excluded from release builds and that partner secrets are not embedded in shipped binaries. Review how attachment paths are validated before being appended to /attachment-proxy URLs.

Security signals we found

01

New network client with bearer-token authentication and customer-key header

02

Optional query-parameter authentication for attachment URLs may expose secrets in logs, browser history, or Referer headers

03

Customer key stored in general preferences box (DB.boxNamePrefs) rather than a dedicated secure store

04

Service singleton defaults to sandbox: true and production baseUrl unless overridden

05

Webhook verifier uses HMAC-SHA256 with constant-time comparison and timestamp tolerance

06

HTTP PATCH/DELETE helpers added without explicit timeout handling visible in the diff

07

Partner access key and secret are compile-time constants in external_api_keys.dart

Risk score

Why this scored 26/100

Our methodology →
Potential impact 4/30
Exploitability 5/25
Stealth signal 6/15
Affected reach 5/15
Confidence 4/10
Evidence quality 2/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.