When using a softr ‘Conditional Form’, with the ‘Destination’ set to ‘Webhook’, you are not able to include the authentication-token with the request.
This is, surely, insane? Why not? If you’re using serverless functions (aws Lambda, Google Run, azure), or any externally hosted backend, STAY AWAY from softr!
It forces you to leave your endpoints totally exposed. When the form is submitted, you can easily see in dev tools the destination webhook inside the payload of the POST request. Once a malicious actor has that, eg my-app.dev/api/update-user-details - it’s game over.
Without the authentication-token, you can’t
a) verify if the request was made from a logged in user
b) find out (securely) which user sent the request
We completely get what you mean — it seems logical to want the authentication token included in webhook requests for user verification. However, Softr doesn’t include auth tokens in form or webhook requests on purpose — it’s actually for your security
If tokens were sent in requests made directly from the browser, they could easily be seen in DevTools or intercepted by anyone with access to the user’s device. That would make it possible for someone to copy the token and impersonate the user.
Instead, the secure approach is to:
Use Workflows or Action Buttons with permissions — these run safely on Softr’s servers, so you can be sure the request comes from an authenticated user.
Or, send the form data to your own backend first, where you can verify the user and then make any needed API calls securely.
So, it’s not a missing feature — it’s actually a protection measure to keep your users’ tokens and data safe.
@joshuabo first of all this is not a vulnerability… it’s to protect no user tokens should be send by default to external systems…
However if you are already dealing with Lambda’s and APIs you still have an option to inject the token via custom code and also take responsibility for it. It’s up to you but this should never be default…
Nonsense, you can see the token in DevTools regardless. DevTools → ‘Storage’ → ‘Cookies’ → {softr website name} → jwtToken, if you have access to the user’s device.
Please stop sharing this misleading advice (this is the second time I’ve heard this)
As softr exposes the webhook destination when the request is made;
If it was once visible (ie they were on a paid plan), but is not visible anymore (they cancelled the paid plan), but took note of the destination
An attacker guesses the destination and payload (eg /api/users/create)
I’m defenceless, I have nothing to authenticate the request. Your assumption, shockingly, fails to account for a malicious actor.
Workflows isn’t an option provided on the form submission button.
I’m not sure what you mean by ‘your own backend first’. That’s the only place my form data is going.
I thought you’re maybe suggesting having a parallel authentication-token system managed by my backend? For example, I add as a hidden input to my form a secondary authentication-token, which can be associated to a user. And perhaps I fetch the secondary authentication-token in the global custom code? However this falls apart at the final hurdle, as I’m only given a limited selection of options to add into my form data:
This is inaccurate. You’re harming users by forcing them to create vulnerable endpoints.
If I was a novice and didn’t know any better, from the (incorrect) advice given by softr support I’d think my endpoint is secure. It’s not. The strategy of ‘there are no malicious actors, it’ll be fine’ is not aprotection measure.
If you’re worried users might misuse the authentication-token, by adding them to every request they make, it’s up to you to educate the user (perhaps a big warning with a short disclaimer if somebody tries to add it to the request) - or provide an alternative system to authenticate requests.
I disagree. Softr forces you to make your endpoint vulnerable. The vulnerability wouldn’t exist without using softr.
If I have an alarm system (my backend), but the chime (softr) requires me to keep the door wide open 24/7, and a malicious actor walks in, who’s at fault?
What external systems? My own backend? Protect me from myself, by exposing myself?
How would you suggest I make a form request with softr that can be authenticated, without using a codeblock? Do you have a solution for, what I would have assumed, a basic requirement of a website?
Does this mean YOU take responsibility if I don’t add any authentication-token, and my endpoint is abused? Or is the reality I’m taking the responsibility either way anyway?
Currently we don’t allow that without custom code.. if you are unhappy and don’t want to do it with a bit of custom code, please consider another platform where you can pass user tokens anywhere without code
Can I request, as an urgent enquiry, for the sake of all your users that basic authentication is added promptly? Or is basic authentication not a priority for softr?
If you don’t want to use tokens, fine, but you should provide a (real) alternative.
Whilst I am unhappy, ultimately I just want the website to be secure. I didn’t think that this would be a big ask… You’re forcing me to look elsewhere. If you don’t provide a solution, I hope others do the same.
I just registered today to this forum, to request this functionality. Awesome that there is a current discussion on this topic. Feels wild that there is no webhook authentication method in place.
Happy to chat.