fix: add credentials include option for HTTP requests

[aymenhmaidiwastaken]

Closes #1868

Adds credentials: 'include' to the client-side fetch calls so cookies are forwarded with HTTP requests. This is needed for setups that rely on cookie-based auth or session management.

Straightforward change — just wiring up the credentials option in the fetch config.

[vercel]

@aymenhmaidiwastaken is attempting to deploy a commit to the Typebot Team on Vercel.

A member of the Team first needs to authorize it.

[baptisteArno]

Thanks for the PR! I'm a bit concerned about the security implications of this change though.

When credentials is undefined, fetch defaults to "same-origin", which already sends cookies for requests to the same domain. Switching to "include" means cookies will be sent with all cross-origin requests too.

Since executeHttpRequest runs in the visitor's browser and targets URLs configured by the bot builder, this would send the visitor's cookies to any arbitrary domain, opening the door to CSRF attacks or session cookie exfiltration.

Could you share more about your use case? What kind of setup requires cookies to be sent cross-origin? "same-origin" should already cover cookie-based auth when the HTTP request targets the same domain as the bot.

[aymenhmaidiwastaken]

Great point — you're right that blindly setting credentials: 'include' on all cross-origin requests is a security risk.

A better approach would be to make this configurable per HTTP request block, so the bot builder can explicitly opt in when they need cross-origin cookies (e.g., hitting their own API on a different subdomain).

I can update the PR to:

1. Add a withCredentials toggle to the HTTP request block settings
2. Only set credentials: 'include' when the builder explicitly enables it
3. Default to the current behavior (undefined / same-origin)

That way it's opt-in and the builder takes responsibility for the target URL. Would that work for you?

[baptisteArno]

Thanks for the suggestion! A per-block toggle is definitely better than a global include, but the underlying risk remains: a malicious bot builder could still enable the toggle and use an HTTP request block to send the visitor's cookies to an arbitrary third-party domain (CSRF / session exfiltration).

Before we go down the implementation path, could you describe your actual use case? What's the setup where same-origin doesn't work for you? For example, are you hitting a subdomain API, a reverse-proxied backend, or something else entirely? Understanding the concrete scenario would help us find the safest solution.