Maybe I don’t understand, but I’m very disappointed with the Grsit forms. The first problem is that there is NO conditional logic carried through from the table (if you have a field that has a dropdown condition, this WILL NOT work in the form). Secondly, and the big one for me, when you publish the form, it grants full access for anyone to write to your tables. Even if we restrict access to the form via that access portion of Grist, it does not apply to a published form. If I’m correct in my findings (and I hope not) - HOW CAN ANYONE use forms safely? - Please tell me I have misunderstood - but this is what my testing has shown
what is your idea of form usage?
afaik, the objective of the forms is to give access to even people outside of your corporation to use them.
They are NOT a way for Grist users to insert data into Grist.
I like the “FORM FORMAT” for users to insert data: insert data and then click PUBLISH/SAVE for the data to get recorded. But I achieved this with custom plugins
You can also leverage access rules and make a pseudo-form using a Card widget, which doesn’t look as fancy but works.
That means when you publish a form, your data is wide open to being corrupted by anyone on the internet. This is a HUGE security hole!!!
Yea I’m starting to get to think Grist is a bit of a joke - its way too juvenile for anyone to use seriously. (As we now have come across more setbacks)
Alan, while your concern is totally valid, I think there’s some BIG confusion from your part regarding the intended purpose of published forms in Grist.
Published forms are meant to collect data from the public, even from people outside your organization or workspace. They’re designed to work like Google Forms or Typeform: a simple entry point for external users to submit records, not a secure, internal-only interface.
When you publish a form, anyone with the link can submit data (write access)… BECAUSE THAT’S THE WHOLE PURPOSE!! It’s not a “security hole,” it’s a design choice: Grist assumes you want public submissions.
More analogy with Google Forms. They can write directly to a spreadsheet on Google Sheets.
When you publish a Google Form and distribute the link, you DO NOT think “Google Forms sucks, it creates a loophole for people to corrupt my data”
That’s the WHOLE purpose of Google Forms. You don´t use Google Forms as a secure way for employees only to insert data into your sheet.
Card Widgets don´t have a SUBMIT or SAVE feature. You type it, it automatically creates a record and changes data.
I will take upon me creating a Super FormCard… or Ultra DataEntryCard. Haven´t decided on the name yet.
Maybe have features similar to the Public Form. But a usage objective similar to Cards.
OBJECTIVES
- Validation/Security rules similar to the common Grist Cards
- cancel, save/submit buttons
- boxes, dividers, section titles and text sections (meaning, text is part of the form, not of the table), images (for logos, etc)
- tabs
1 Like
Wow, you didn´t understand the purpose of Forms, called it, WRONGLY, a security hole, and calls Grist juvenile based on YOUR misunderstanding?
1 Like
Not at all - ANY product that allows for a mechanism for bypassing security on the database (which is what is happening here) is a problem - you’re effectively giving the world “write access” to the DB even though it is not granted in the DB access. That’s wide open for a DOS attack!
this isn’t a DB security bypass, it’s a controlled, write-only endpoint, just like any public web form.
A published Grist Form can only create new records, never read or edit existing ones. That means no user data is exposed and no privileges are escalated.
Of course, since it’s anonymous input, rate-limiting or CAPTCHA would be a good enhancement to prevent spam or DOS-style abuse, but the current behavior is by design, similar to how Google Forms or Airtable Forms work.
If you need internal, access-controlled forms (with validation, conditional logic, and save/cancel), those should be built inside Grist itself using a Card widget or custom widget, not a published public form.
Hi @Alan_Scott , I am Dmitry, a co-founder of Grist. You have a few team members stressing out if there is some vulnerability in forms we need to fix, or a misunderstanding. The reason is: we take security very seriously, and Grist is a product specifically for those who need to trust their tool, with robustness, security, and privacy.
To set clear expectations: Forms are a feature of Grist to enable collecting data from public users. It is documented here. If you have such a need, you can add a “Form” widget, design it, and you may publish this form. When publishing, an alert is shown with what exactly would be allowed: public users will be able to submit new entries, and would be able to use dropdowns for fields included in the form (showing dropdowns is exposing something in the document, so the message is careful to point that out).
Forms are not useful for working with collaborators on a document. For collaboration, Grist has always had other ways to work on data: tables, cards, card lists, custom widgets, with many features around them (linking, filtering, etc). Those are only available to people the document is shared with. If you were hoping to use forms in a way limited to your collaborators, that’s a misunderstanding. For that, use the Card widget. It would be a reasonable feature request to extend Forms to this use case (because Forms UI has some advantages over Cards), and has come up before. Perhaps this is what caused the confusion.
Publishing a form intentionally makes it public, regardless of access rules. This way you don’t have to share your document widely (e.g. make it public with link-sharing) if all you want is to have a public form that flows into it.
This allows forms to be used like other form builders out there, e.g. Google Forms. You can compare behavior to other such products. Once a form is published, you can share the link with anyone. They’d be able to fill in the form and submit, and you’ll see a new record in your table. You can unpublish the form as well, and the link will stop working.
The forms functionality does not give any other permissions.
Any attack via forms (e.g. making any other change to a document, accessing document data, etc) would be a vulnerability. If you find any wrong behavior, please do report it, with enough details to reproduce the issue, as we take such things seriously.
5 Likes