<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[How to deal with sign-up spam?]]></title><description><![CDATA[<p dir="auto">I have self-service registration turned on. I am getting some valid users, but a bunch of spam accounts.</p>
<p dir="auto">What is the best way to deal with this?</p>
<p dir="auto">Thanks!</p>
]]></description><link>https://fusionauth.io/community/forum/topic/2862/how-to-deal-with-sign-up-spam</link><generator>RSS for Node</generator><lastBuildDate>Fri, 15 May 2026 23:52:22 GMT</lastBuildDate><atom:link href="https://fusionauth.io/community/forum/topic/2862.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 04 Feb 2025 20:17:41 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to How to deal with sign-up spam? on Thu, 18 Sep 2025 13:39:59 GMT]]></title><description><![CDATA[<p dir="auto"><a class="mention plugin-mentions-user plugin-mentions-a" href="https://fusionauth.io/community/forum/uid/428">@atakan</a> <a class="mention plugin-mentions-user plugin-mentions-a" href="https://fusionauth.io/community/forum/uid/1785">@theogravity-sb</a>  Seems like two different issues here.</p>
<p dir="auto"><a class="mention plugin-mentions-user plugin-mentions-a" href="https://fusionauth.io/community/forum/uid/1785">@theogravity-sb</a> is talking about attackers using the Google identity provider to create accounts with malicious names. <a class="mention plugin-mentions-user plugin-mentions-a" href="https://fusionauth.io/community/forum/uid/428">@atakan</a> is talking about attackers using self-service registration to create accounts with malicious names. They seem related but not identical. When you are allowing people to create their own identity and/or delegate to another source of identity, you decrease friction but give up some control.</p>
<p dir="auto">The bad news is that FusionAuth has nothing out of the box to stop this behavior.</p>
<p dir="auto">The good news is that you can build an integration to stop it. There are email verification services that give you a risk factor for email addresses and you can check that before you allow for registration or login.</p>
<p dir="auto">Here's a blog post I wrote about <a href="https://fusionauth.io/blog/identity-verification-before-registration" rel="nofollow ugc">leveraging a third-party service to check the validity of emails provided during registration</a>. This post uses a <a href="https://fusionauth.io/docs/extend/code/lambdas/self-service-registration" rel="nofollow ugc">self-service registration validation lambda</a>, but for the Google identity provider use case, you could use the <a href="https://fusionauth.io/docs/extend/code/lambdas/login-validation" rel="nofollow ugc">login validation lambda</a> and perform the same type of check.</p>
<p dir="auto">While I used Fideo because it had a good API and I had a connection there, I have not done an extensive survey of the landscape of email verification services, so cannot recommend any particular service.</p>
]]></description><link>https://fusionauth.io/community/forum/post/8378</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/8378</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Thu, 18 Sep 2025 13:39:59 GMT</pubDate></item><item><title><![CDATA[Reply to How to deal with sign-up spam? on Mon, 15 Sep 2025 22:12:38 GMT]]></title><description><![CDATA[<p dir="auto"><a class="mention plugin-mentions-user plugin-mentions-a" href="https://fusionauth.io/community/forum/uid/20">@dan</a> It is like that. They use regular /oauth2/register flow to create spam accounts. Even though we deploy WAF, it usually can't catch them as they obey the rate-limits.  <img src="/community/forum/assets/uploads/files/1757974173772-screenshot-2025-09-15-at-6.09.30-pm-resized.png" alt="Screenshot 2025-09-15 at 6.09.30 PM.png" class=" img-fluid img-markdown" /></p>
]]></description><link>https://fusionauth.io/community/forum/post/8373</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/8373</guid><dc:creator><![CDATA[atakan]]></dc:creator><pubDate>Mon, 15 Sep 2025 22:12:38 GMT</pubDate></item><item><title><![CDATA[Reply to How to deal with sign-up spam? on Wed, 12 Feb 2025 20:22:57 GMT]]></title><description><![CDATA[<p dir="auto"><a class="mention plugin-mentions-user plugin-mentions-a" href="https://fusionauth.io/community/forum/uid/1785">@theogravity-sb</a> Hmmm. So the issue is that someone is registering with a gmail account they control but it looks like this:</p>
<p dir="auto"><a href="mailto:foo@gmail.com" rel="nofollow ugc">foo@gmail.com</a> with a name of &lt;Dan <a href="https://evil.com" rel="nofollow ugc">https://evil.com</a>&gt; which is being turned into a link?</p>
<p dir="auto">Or am I misunderstanding your question?</p>
]]></description><link>https://fusionauth.io/community/forum/post/7822</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/7822</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Wed, 12 Feb 2025 20:22:57 GMT</pubDate></item><item><title><![CDATA[Reply to How to deal with sign-up spam? on Tue, 11 Feb 2025 19:05:25 GMT]]></title><description><![CDATA[<p dir="auto">There's also another kind of spam that we're noticing. At least for Google IdP accounts, scammers are adjusting their name to include malicious URLs (without even using link tags). The gmail UI will unfortunately render them as links.</p>
<p dir="auto">Does FA have some built-in functionality to deal with this scenario?</p>
]]></description><link>https://fusionauth.io/community/forum/post/7820</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/7820</guid><dc:creator><![CDATA[theogravity-sb]]></dc:creator><pubDate>Tue, 11 Feb 2025 19:05:25 GMT</pubDate></item><item><title><![CDATA[Reply to How to deal with sign-up spam? on Tue, 04 Feb 2025 20:21:49 GMT]]></title><description><![CDATA[<p dir="auto">You have a variety of ways to approach this, with different tradeoffs around functionality, effort and cost. It also matters if the spam accounts are being signed up for by humans or bots.</p>
<ul>
<li>
<p dir="auto">use a webhook to prohibit bogus users from being created by setting the <code>user.create</code> webhook to be transactional. You'd then write a service that could examine the user object, including email address or other attributes, and return a non-200 value to fail their creation. <a href="https://fusionauth.io/docs/extend/events-and-webhooks/writing-a-webhook" rel="nofollow ugc">Details on webhooks</a>. This is available on the community plan.</p>
</li>
<li>
<p dir="auto">use email verification to prevent spam users without an email inbox from using your application. <a href="https://fusionauth.io/docs/lifecycle/manage-users/verification/gate-accounts-until-user-email-verified" rel="nofollow ugc">Details on configuring this functionality</a>. This is available on any paid plan.</p>
</li>
<li>
<p dir="auto">use a self-service registration lambda, and examine the email address and other information for a user. If a user is obviously bogus or matches a pattern, you could return a message stating they can't register, or to call you for assistance. <a href="https://fusionauth.io/docs/extend/code/lambdas/self-service-registration" rel="nofollow ugc">Details on using this lambda</a>. This is available on any paid plan.</p>
</li>
<li>
<p dir="auto">turn on <a href="https://fusionauth.io/docs/operate/secure-and-monitor/advanced-threat-detection#captcha" rel="nofollow ugc">CAPTCHA</a> which will make it harder for bots to sign up. This requires an enterprise plan.</p>
</li>
</ul>
]]></description><link>https://fusionauth.io/community/forum/post/7803</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/7803</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Tue, 04 Feb 2025 20:21:49 GMT</pubDate></item></channel></rss>