Harden rate limiting and audit trails for sensitive mutations

[grantfox-oss]

Prevent abuse of admin, auth, and payment-sensitive mutations by combining request throttling, contextual audit logs, and explicit anomaly handling.

• Affected files: app/backend/src/app.module.ts, app/backend/src/config/rate-limit.config.ts, app/backend/src/auth/guards/custom-throttler.guard.ts, app/backend/src/auth/decorators/, app/backend/src/audit/audit.service.ts, app/backend/src/audit/audit.module.ts, app/backend/src/payments/payments.controller.ts, app/backend/src/marketplace/marketplace.controller.ts, app/backend/test/rbac.e2e-spec.ts
• Acceptance criteria:
  • Sensitive mutation endpoints apply stricter per-user and per-IP throttling policies.
  • Abuse events record actor identity, route context, and request metadata in immutable audit logs.
  • Configurable limits and operator guidance are documented for production deployment.

[ayomidearegbeshola29-dev]

I’d like to take this on. I have experience working with backend authentication, authorization, API security, and audit-focused systems, and I’m comfortable working across NestJS modules, custom guards, controllers, and integration tests. I’ll treat this as a security-control implementation rather than simply adding a generic rate limiter, with the goal of making sensitive mutations resistant to both automated abuse and repeated attempts from distributed clients.

I’ll first review the existing authentication, RBAC, throttling, and audit architecture so the implementation fits the current application instead of introducing a parallel security mechanism. In particular, I’ll inspect app/backend/src/app.module.ts, the existing configuration conventions, the custom throttler guard, authentication decorators, and the current audit service/module before deciding where each control belongs.

For throttling, I’ll introduce explicit configurable policies for sensitive operations and distinguish between per-user and per-IP limits. Payment-sensitive, administrative, and authentication mutations will receive stricter limits than ordinary read endpoints. Where a verified user identity is available, the throttling key will incorporate that identity while still retaining IP-based protection to prevent abuse through compromised accounts or multiple accounts from the same source.

I’ll keep the limits configurable through rate-limit.config.ts rather than hardcoding operational values into individual controllers or guards. The configuration will make it possible for operators to tune thresholds independently for different classes of sensitive operations without requiring code changes.

I’ll extend custom-throttler.guard.ts to handle the contextual information required for these policies and add decorators where appropriate so controllers can explicitly identify particularly sensitive mutations. This should keep security policy visible at the endpoint level while avoiding duplicated throttling logic across PaymentsController, MarketplaceController, and future sensitive endpoints.

For abuse detection and auditability, I’ll integrate the throttling/anomaly path with AuditService. When a request exceeds a configured threshold or triggers an explicit anomaly condition, the resulting audit record will capture the relevant actor identity when available, route/controller context, source IP or appropriate request metadata, timestamp, action, and the reason the event was generated.

I’ll be careful about what gets written to the audit trail. Request metadata will be useful for investigation, but credentials, authorization headers, payment secrets, tokens, and other sensitive payload data will not be copied into immutable logs. The audit events should provide enough context for operators to understand and correlate an incident without creating a secondary source of credential or personal-data leakage.

For the payment and marketplace controllers, I’ll identify the mutation endpoints that can materially change account, payment, marketplace, or administrative state and apply the appropriate stricter policy. I’ll avoid unnecessarily throttling harmless read operations or unrelated routes.

Testing will include both normal and adversarial cases. I’ll extend rbac.e2e-spec.ts and add focused tests where necessary to verify:

• Sensitive mutations succeed under the configured threshold.
• Repeated requests eventually receive the expected throttling response.
• Per-user limits are enforced independently of IP limits.
• Per-IP limits still protect endpoints when user identity is unavailable.
• Different users do not unintentionally share a user-specific throttle bucket.
• Authentication/admin/payment-sensitive routes receive the intended stricter policies.
• Abuse events create audit records containing actor and route context.
• Audit records do not contain credentials, tokens, or sensitive request payloads.
• Invalid or missing identity information is handled safely rather than bypassing throttling.
• Concurrent requests cannot trivially circumvent the configured limits.
• Existing authorized behavior remains intact.
• Existing RBAC protections continue to work alongside throttling.

I’ll also explicitly consider anomaly cases such as repeated failed authorization attempts, bursts of payment mutations, requests from an identity/IP combination that suddenly exceeds normal behavior, and requests where identity information is malformed or unavailable. The implementation will fail closed for the security control without turning ordinary infrastructure errors into unexpected authorization bypasses.

Finally, I’ll document the production configuration and operator guidance, including the available limits, recommended starting values, how per-user/per-IP policies interact, what constitutes an abuse event, how to monitor the audit trail, and how operators can tune the limits without modifying application code.

Before submitting, I’ll run the relevant unit/e2e test suites and build/type-check commands, review the final diff for accidental logging of sensitive data, and verify that the new security controls remain compatible with the existing authentication and RBAC architecture.

[patrickNwafo]

Hi, maintainer can i work on this issue?

[grantfox-oss]

🦊 GrantFox — @patrickNwafo has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #551)
2. Your PR will be reviewed by the BlockDash-Studios maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!

@patrickNwafo's PR #558 was approved and merged by @MaryammAli.

🏆 @patrickNwafo: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (605 total points). Track your full progress on GrantFox.

👏 Great work, @patrickNwafo! Keep contributing to BlockDash-Studios.