Skip to content

Fix/971 972 973 974 security compliance hardening - #1176

Merged
Mystery-CLI merged 5 commits into
Ethereal-Future:mainfrom
Lex-Studios:fix/971-972-973-974-security-compliance-hardening
Aug 26, 2026
Merged

Mystery-CLI merged 5 commits into
Ethereal-Future:mainfrom
Lex-Studios:fix/971-972-973-974-security-compliance-hardening

Conversation

@Lex-Studios

Copy link
Copy Markdown
Contributor

Security & Compliance Hardening

Implements critical security fixes and compliance enhancements across JWT verification, rate limiting, IP whitelist, and AML screening.

Changes

Issue #971: Remove hardcoded rate-limit headers middleware that emitted static, meaningless values. Actual rate-limit headers now come from express-rate-limit middleware only.

Issue #972: Add JWT verification security hardening with algorithm pinning to HS256, issuer validation, and distinct audience claims for access vs refresh tokens.

Issue #973: Implement persistent IP whitelist with database backing, input validation (IPv4/IPv6/CIDR), audit logging, and multi-instance synchronization.

Issue #974: Move AML screening to run synchronously before Stellar payment submission. Add account hold/review mechanism. Block high-severity violations before calling Stellar
service.

Test Coverage

  • JWT verification tests covering algorithm pinning and audience validation
  • IP whitelist tests for validation, persistence, and audit logging
  • AML pre-submission screening tests for violation detection and account holds

Closes #971
Closes #972
Closes #973
Closes #974

- Removed rateLimitHeaders() middleware that was emitting static, meaningless X-RateLimit-* header values
- The actual rate-limit headers should come from express-rate-limit middleware which provides accurate, dynamic values
- Fixes issue where clients could be misled about remaining quota
- Pin JWT algorithm verification to HS256 only (prevents algorithm substitution attacks)
- Add issuer ('future-app') and audience claims to all tokens
- Use distinct audiences: 'future-api' for access tokens, 'future-refresh' for refresh tokens
- Add verifyRefreshToken() function with explicit audience validation
- Update refresh endpoint to use verifyRefreshToken() instead of generic verifyToken()
- Add comprehensive test coverage for algorithm pinning, issuer/audience validation, and cross-token-type attack prevention
- Ensures tokens cannot be misused across different contexts
- Add IPWhitelist Prisma model for persistent storage in database
- Replace in-memory Set with database-backed cache with in-memory caching layer
- Add IP address validation (IPv4, IPv6, and CIDR notation)
- Implement audit logging for all mutations (add, remove, clear) via logAdminAction
- Add input validation to reject malformed IP addresses before persistence
- Load environment variable whitelist on startup for backward compatibility
- Add startup logging showing loaded whitelist size
- Initialize cache from database on server startup
- Add comprehensive test coverage for validation, persistence, and audit logging
- Ensure changes synchronize through database, enabling multi-instance deployments
…ission

- Add amlStatus field to User model (CLEAR, HELD_FOR_REVIEW, BLOCKED)
- Add amlHoldReason and amlHoldDate fields for tracking account holds
- Implement screenTransactionPreSubmission() for blocking violations before Stellar submission
- Separate pre-submission rules (LARGE_TX, STRUCTURING, VELOCITY) from post-submission
- Keep UNVERIFIED_USER and other rules for post-submission monitoring only
- Add holdAccountForReview() to place accounts under compliance review
- Add clearAccountHold() to restore trading capability after review
- Add getTransactionHistory() with transactional locking via database queries
- Integrate pre-submission screening into /api/v1/stellar/send endpoint
- Return 403 with detailed violation information when blocked
- Prevent Stellar service from being called for blocked transactions
- Run post-submission screening asynchronously for monitoring (no-await)
- Add comprehensive test coverage for all pre-submission scenarios
- Ensures HIGH-severity violations prevent payment submission and trigger account holds
@drips-wave

drips-wave Bot commented Aug 26, 2026

Copy link
Copy Markdown

@Lex-Studios 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

@Mystery-CLI
Mystery-CLI merged commit f1306a6 into Ethereal-Future:main Aug 26, 2026
3 of 32 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment