如何防止恶意用户循环发送HTTP POST请求至订阅接口？

Hey there! Let’s tackle this annoying spam problem with your subscription modal. When your POST endpoint is exposed in the HTML, bots or malicious users can easily hammer it with fake requests to flood your database—super frustrating, but we’ve got several solid fixes to lock this down.

Core Solutions to Implement #

1. Add a CAPTCHA to Verify Human Users #

This is one of the most effective ways to block automated scripts. CAPTCHAs force users to prove they’re human before submitting their email, which stops those looped POST requests dead in their tracks.

• For a user-friendly option, go with reCAPTCHA v3 (it works in the background without requiring users to click boxes) or v2 (the classic "I'm not a robot" checkbox).
• How to set it up:
  • Frontend: Include the reCAPTCHA script in your modal, and add the generated token to your POST request body.
  • Backend: Before processing the subscription, send the token to Google’s verification endpoint to confirm it’s valid. Only proceed if the verification passes.

2. Implement Rate Limiting #

Limit how many times a single IP address (or user session) can send requests to your subscription endpoint within a specific timeframe. This prevents someone from spamming thousands of requests in a loop.

Example for ASP.NET (if that’s your stack):

// Using ASP.NET Core Rate Limiting middleware
builder.Services.AddRateLimiter(options =>
{
    options.AddFixedWindowLimiter("SubscriptionLimit", opt =>
    {
        opt.Window = TimeSpan.FromMinutes(1);
        opt.PermitLimit = 3; // Allow max 3 requests per minute per IP
        opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
        opt.QueueLimit = 0;
    });
});

// Apply the limiter to your subscription endpoint
app.UseRateLimiter();

[HttpPost("subscribe")]
[EnableRateLimiting("SubscriptionLimit")]
public async Task<IActionResult> Subscribe([FromBody] SubscriptionRequest request)
{
    // Your subscription logic here
}

If you’re using Nginx, you can also configure rate limiting directly in your server config to block spam at the web server level.

3. Use CSRF Tokens #

Cross-Site Request Forgery tokens ensure that only requests originating from your own website are accepted. Even if someone finds your endpoint URL, they won’t have the valid CSRF token needed to submit a request.

• Frontend: When rendering the subscription modal, generate a unique CSRF token (stored in your user’s session or a cookie) and include it as a hidden input in the form.
• Backend: When receiving the POST request, check that the token from the request matches the one stored in the user’s session. Reject the request if they don’t match.

4. Validate Email Addresses & Block Repeat Offenders #

Add layers of validation to filter out obvious junk:

• Format validation: Use regex or a trusted library to check that the submitted email follows a valid format before saving it to the database.
• Duplicate check: If an IP tries to submit the same invalid email multiple times, temporarily block that IP for 15–30 minutes.
• Disposable email blocking: Use a list of known disposable email providers (like Mailinator) to reject those addresses outright.

5. Obscure the Endpoint (As a Secondary Measure) #

While this isn’t a standalone fix, it adds an extra layer of difficulty for attackers:

• Don’t hardcode the POST URL in your HTML. Instead, load it dynamically via an AJAX request when the modal opens.
• Use a non-obvious endpoint path (e.g., /api/subscribe/2f9d7a8b instead of /api/subscribe).

Final Notes #

Combine 2–3 of these methods for the best protection—for example, CAPTCHA + Rate Limiting + CSRF Tokens will cover almost all attack scenarios. Start with rate limiting and CSRF tokens as quick wins, then add CAPTCHA for maximum security.

内容的提问来源于stack exchange，提问作者ryan1555