Sometimes, visitors need access without having to sign in: to complete a registration form, browse a public catalogue, or use a kiosk. FileMaker’s Guest account may seem like a convenient solution, but it deserves careful attention:
It exists in every FileMaker file and has a predictable name. It is therefore the easiest account attack bots try.
It cannot be protected with a password. When enabled, it allows access without authentication.
Its permissions may be broader than intended. If the Guest account has access through WebDirect, the Data API (fmrest), OData, or XML, unauthenticated visitors may be able to access any data its privilege set allows them to see.
Claris recommends leaving the Guest account disabled unless it is needed. (Claris Security Guide, “Don’t enable the Guest account”).
Our recommendation is stricter for Data API integrations: use a dedicated account, and never grant the Guest account the fmrest extended privilege. A website or program that uses the Data API always logs in with a named account and its password. The Guest account must never have the fmrest privilege.
The most common mistake: a shared privilege set
Guest access is often expanded by accident. Here is a typical example:
1- The Guest account is assigned a privilege set, such as “Read-Only Access” or “Data Entry Only”;
2- Other accounts use the same privilege set: staff accounts, an integration account, or an account used to run server-side scripts.
3- Someone later adds an extended privilege, such as fmrest for an integration or fmwebdirect for a colleague. They might also grant access to another table;
4- The Guest account automatically receives those additional permissions. Access has just been expanded, potentially without anyone noticing.
The rule: a dedicated privilege set per use
Any account used for public access should have its own privilege set, separate from those used by staff or integrations. In Manage Security, check the privilege set assigned to each account. Make sure the set used for public access is not also assigned to accounts with different needs.
A better approach
Instead of using Guest, create a dedicated account for the public form or other specific feature:
1- Give it only the permissions that feature requires;
2- Use a hard-to-guess account name and a long, unique password;
3- For FileMaker Pro, Go, or WebDirect, configure automatic login if visitors need access without entering credentials.. They still have nothing to type.
Visitors can still use the feature without signing in manually. The key protection is that the account has a dedicated, tightly restricted privilege set.
Setting it up (FileMaker Pro, with a full-access account)
1. Create a dedicated privilege set, for example “Public form” (File > Manage > Security). Don’t reuse an existing set: tthis one must be used only by this account. Give it the minimum:
- Records: create only, and only in the form’s table. No viewing of other records, no access to other tables.
- Layouts: only the form’s layout(s).
- Scripts and value lists: only those the form uses.
- Printing and exporting: off.
- Extended privileges: only one, for the channel used:
fmwebdirectfor WebDirect,fmrestfor the Data API (see below), orfmappfor FileMaker Pro and Go. Neverfmxmlorfmodataunless there is a specific need.
2. Create the account and assign it this privilege set, with:
- a name that is hard to guess (not “web”, “form”, “public” or the file name);
- a long password (16 characters or more), different from all others.
3. For FileMaker Pro, Go and WebDirect: turn on automatic login with this account.
Go to File > File Options, Open tab, tick Log in using, then Account Name and Password, and enter the account and its password. Source: Claris, “Setting file options”.
4. Disable the Guest account: in Manage Security, select Guest and untick Active. If you must keep it, at least remove all its extended privileges (fmrest, fmwebdirect, fmxml, fmodata), and give it a privilege set no other account uses.
5. Test from a browser or computer with no saved credentials:
- the form works;
- everything else is blocked (other layouts, other records, exporting).
Good to know before you start
- Treat this account’s password as public. Anyone who opens the file is logged in with this account. That is exactly why it must not be able to do anything beyond what the form requires.
- Data API (form on a website): a named account, never Guest.
- Automatic login does not apply to the Data API. The website authenticates using the dedicated account’s name and password (Claris, Data API “Log in to a database session”).
- This login must happen on the server side (the program that receives the form), never in the web page code: a password included in the page’s source code is visible to anyone.
- WebDirect: the automatic login in step 3 also applies to WebDirect visitors. You can also log visitors in from your home page, with an HTTP POST request that contains the account and password (Claris, “Signing in with HTTP POST”). Either way, the minimum-permissions rule applies.
- Several files: repeat this in every file that used the Guest account. Use the same account name everywhere, but not necessarily the same password.
In short
| Before | After |
|---|---|
| Guest account active, known to everyone, no password | Guest account disabled |
| Privilege set shared with other accounts, rights widened without anyone knowing | Privilege set reserved for the dedicated account |
| Often broad rights, several channels open (Data API, WebDirect…) | Dedicated account: one channel, create only, one layout |
| Visitors may be able to access more data than intended | A visitor can only fill in the form |
Need help? Contact us
