DEV Community

HayesSterling2614
HayesSterling2614

Posted on

Go Signup Risk Gates: Server-Side CAPTCHA Checks Before Account Creation

#auth #botdefense #captcha #go

A support portal can lose its signup queue before anyone notices: the alert page shows a spike in account-creation requests, agents report disposable inboxes, and the recovery team is already handling accounts created by scripts. The least complex fix is a server-side CAPTCHA decision made before the account transaction, combined with a device-fingerprint signal and an explicit recovery path. The browser widget is only a signal collector; the server owns the decision.

Short answer: verify the CAPTCHA token on your backend, bind the result to the signup attempt and device risk, then create the account only after the response passes freshness, hostname, and action checks. Keep a low-risk path for legitimate support customers and step up suspicious attempts instead of rejecting everyone.

When does a signup alert become an account-recovery incident?

Start with the page that fires. An on-call engineer should see signup attempts per minute, token-verification outcomes, challenge latency, and the percentage routed to recovery review. A single total called captcha_failed is not enough: it hides expired tokens, mismatched actions, replay attempts, and a provider timeout behind one red line. I want the alert payload to carry a trace ID that an agent can paste into the support console, the device-risk band without the raw fingerprint, the action and hostname returned by verification, and the exact transition that produced step_up; that makes a midnight investigation a bounded query instead of a hunt through web logs, and it lets the recovery lead compare false positives with actual abuse on the next morning's report.\n\nMeasure twice.

Work backward from the alert to the signal that should have fired earlier. For a customer-support portal, join the signup event with a stable, privacy-reviewed device fingerprint, ASN or network reputation, email-domain class, and the eventual recovery outcome. Do not retain raw fingerprint material indefinitely; store a keyed digest and a short retention window, then document who can query it. The useful question is not “did the widget appear?” but “did this attempt create a recovery burden?”

The threshold needs a cost model. A false negative creates an account that may generate tickets, abuse agent messaging, or consume invitation capacity. A false positive blocks a real customer who may already be locked out. Page the team on sustained recovery impact, not on a five-minute burst of harmless challenge failures. Your mileage may vary because a consumer signup flow and an invite-only support console have very different acceptable friction.

Keep it boring.

How should server-side CAPTCHA verification shape the signup transaction?

Treat verification as an input to a state machine, not as a boolean attached to a form. The client submits a token and an opaque attempt ID. The backend checks that the token is fresh, was issued for this action and hostname, and has not been consumed. It then evaluates device risk and chooses allow, step_up, or deny. Only allow can reach the account-creation write.

Here is a deliberately small Go boundary. The provider-specific URL belongs behind this interface, so changing challenge systems does not spread through handlers or recovery code.

type CaptchaResult struct {
    Success  bool
    Action   string
    Hostname string
    IssuedAt time.Time
}

type CaptchaVerifier interface {
    Verify(ctx context.Context, token, remoteIP string) (CaptchaResult, error)
}

func admitSignup(ctx context.Context, v CaptchaVerifier, token string, ip string, attempt Attempt, risk Risk) (Decision, error) {
    result, err := v.Verify(ctx, token, ip)
    if err != nil {
        return DecisionStepUp, err
    }
    if !result.Success || result.Action != "signup" || result.Hostname != attempt.Hostname {
        return DecisionDeny, nil
    }
    if time.Since(result.IssuedAt) > 2*time.Minute || attempt.Consumed {
        return DecisionDeny, nil
    }
    if risk.Score >= 80 {
        return DecisionStepUp, nil
    }
    return DecisionAllow, nil
}
Enter fullscreen mode Exit fullscreen mode

The two-minute value is a policy example, not a universal truth; set it from token semantics and replay testing. Make the verification call bounded by a deadline, record a correlation ID, and make the attempt consume operation idempotent. A retry must not create two accounts or turn a provider timeout into an accidental allow.

What fails in production when the gate is bolted onto the form?

The common failure mode is ordering. Teams verify a token after inserting the user row, then discover that rejected signups still trigger welcome mail, quota allocation, and recovery records. Put the gate before side effects, and use an outbox only after the decision is durable.

Another trap is trusting client claims. A hidden field saying action=signup proves nothing; compare the server-observed action and hostname from the verification response. Never log the token itself. Redact email addresses in high-cardinality labels, because a botnet can turn your metrics backend into a second denial-of-service target. The same discipline applies to retries: preserve one attempt record, attach every verifier call to it, and make the final decision monotonic, so a late success cannot overwrite a prior denial after an agent has already offered a recovery link. That detail matters in support systems where a customer can refresh a browser, open a second tab, and contact an agent before the first request has finished.

Test the unhappy paths as first-class behavior: expired token, reused token, wrong hostname, malformed response, verifier timeout, duplicate attempt ID, and a recovery request immediately after denial. Run these tests against a fake verifier in unit tests and a controlled challenge in staging. Inject latency so the SLO covers the whole admission path, not just your application handler.

A capacity and recovery policy that operators can defend

I would set an initial SLO such as 99.9% of verification decisions completing within 800 ms, then check whether that budget fits the support portal's login and recovery targets. Reserve capacity for step-up traffic; otherwise a challenge surge can starve ordinary signups and make the alert self-amplifying. Keep a circuit-breaker policy explicit: a verifier outage should fail closed for high-risk attempts, while an invite with a previously authenticated support administrator can follow a separately audited path.

Decision Evidence Account action Recovery consequence
Allow Fresh token, matching action and host, low device risk Create account and emit outbox event Normal email verification
Step up Valid token with high risk or unusual velocity Require email link or agent review Creates a traceable queue item
Deny Replay, expired token, or policy violation No account-side effects Show a retry path without revealing the rule

The catch is operational: this design is not suitable when you cannot maintain a recovery queue, privacy review, and an audited exception path. In that case, use an invite-only flow or a simpler rate-limited registration process until those controls exist. A CAPTCHA alone is not an identity proof, and it should never be the only route back into a customer account.

References

Further reading

Top comments (0)