Our convex is current under attack from spamming account creation
Our convex is current under attack from spamming account creation, please give some suggestion from detecting real browser request vs script before convex auth
9 Replies
If you're actively under attack and concerned about resources you can pause your deployment
Can you help me understand the scale of attack? Eg., how many account creation attempts how often (roughly)
Around 100k account was created by this script, we had to turn off user signup with a login type to mitigate the impact
Is there way to set up CORS on convex query and mutation? Our idea rn is to setup httpAction wrapper, not sure if there is an easier or better approach
No. CORS only applies to HTTP requests, and Convex queries and mutations work via websockets. The HTTP action wrapper would work. Not as convenient, but definitely more secure.
CORS only applies to requests from secure browsers, if this attack is originating from a server it won't have any impact. But I also wouldn't expect your sign up function to be a query or mutation - what are you using for auth?
Oh right, thanks for the pointing out this
Our auth is custom built in-house to support some web3 features. There are multiple steps so action/query/mutation are all involved
Is there anyway to prevent convex server to be accessed by a script? I think K8s can do that with VPS so only FE domain can access BE server, is there anything similar for convex?
@erquhart @Clever Tagline Would like to follow up on this here
If you're asking for a way to only allow Convex to respond to requests from your own front end, that's a matter of authentication. For public (non-internal) queries and mutations, ensure that the user is logged in and authenticated before allowing the function to do anything. For HTTP endpoints, require a token. Beyond that, I'm not sure what else to recommend.
is it possible for an attacker to still call a script that access Convex BE if they can get the authenticated token/session key from an logged session, in way similar to how some scrapper would paste in a fake bearer token to imitate an authenticated user?
As a rule, if a client can do it, a server can do it. Your Convex backend has to handle external requests from your client, so it will always be possible for an attacker to mimic a legitimate client. In an actual attack scenario, Convex does work to mitigate impact. You can also use rate limiting to keep a threshold for total signups if fake signups are a concern: https://www.convex.dev/components/rate-limiter
Got it thanks for the heads up, will keep in mind and start working on additional protection on top of user auth