fix: resolve security issues #697 #698 #699 #700

[Grace-CODE-D]

Summary

This PR resolves four security and validation issues across the API and backend services.

---

#697 — Bearer token case sensitivity in WebSocket auth middleware

File: api/src/websocket/middleware/auth.ts

The extractToken function previously stripped the Bearer prefix using a case-insensitive regex (/^Bearer\s+/i). The fix replaces this with an explicit toLowerCase().startsWith('bearer ') check followed by a fixed-length slice(7), making the case normalization unambiguous and matching the approach described in the issue.

// Before
return authToken.replace(/^Bearer\s+/i, '');

// After
if (authToken.toLowerCase().startsWith('bearer ')) {
  return authToken.slice(7);
}
return authToken;

Closes #697

---

#698 — ADMIN_SECRET_KEY stored without rotation mechanism

File: RUNBOOK.md

Added a new Section 7: Rotate ADMIN_SECRET_KEY (Service-Level Key) covering:

• Recommendation to store ADMIN_SECRET_KEY in AWS Secrets Manager or HashiCorp Vault with automatic rotation instead of a plain environment variable.
• Step-by-step manual rotation procedure: generate new keypair → authorize new key on-chain via governance → update the secret → redeploy service → revoke old key on-chain → verify removal.

Closes #698

---

#699 — No rate limiting on webhook registration endpoint

File: backend/src/webhooks/service.ts

Added a MAX_WEBHOOKS_PER_ACCOUNT = 10 constant and enforced it inside registerWebhook before writing to the store. If the total registered webhook count is already at the limit, the method throws with a descriptive error, preventing an attacker from registering thousands of webhook URLs that would trigger mass outbound HTTP requests per event.

const existing = await this.store.getAllWebhooks();
if (existing.length >= MAX_WEBHOOKS_PER_ACCOUNT) {
  throw new Error(`Maximum webhook limit of ${MAX_WEBHOOKS_PER_ACCOUNT} webhooks per account reached`);
}

Closes #699

---

#700 — No input length limits on string fields in request validation

File: api/src/schemas/requestValidation.ts

• Added memoSchema with .max(28) per the Stellar text memo specification (28-byte limit).
• Added memo: memoSchema to createRemittanceSchema so memo is validated at the schema layer.
• Added explicit .max(56) to the token field in createRemittanceSchema to complement the existing pattern constraint.

export const memoSchema = Joi.string()
  .max(28)
  .optional()
  .messages({
    'string.max': 'memo must not exceed 28 characters (Stellar text memo limit)',
  });

Closes #700

---

Test plan

• WebSocket clients sending bearer <token>, BEARER <token>, and Bearer <token> all authenticate successfully
• Attempting to register an 11th webhook returns a 400/422 error with the limit message
• API requests with a memo longer than 28 characters are rejected with a validation error
• ADMIN_SECRET_KEY rotation runbook steps are verified in a staging environment

🤖 Generated with Claude Code

[vercel]

@Grace-CODE-D is attempting to deploy a commit to the Harold's projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@Grace-CODE-D Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits