Automated attacks constantly scan the internet for FileMaker Servers. They list the files each server hosts, try common account names and weak passwords against the Admin Console, Data API, OData, and XML, and once inside, look for API keys and other stored credentials. Claris has confirmed the attacks in its Community security notice.
Attacks like these rarely depend on a flaw in FileMaker. They succeed against weak accounts and exposed services, and you can start closing those gaps today. Each checklist starts with the critical steps, then the next steps to plan.
FileMaker Server Checklist
Critical: Do Today
☐ Limit Who Can Reach Your Server. This is the most effective step. Restrict access to known IP addresses with a firewall or VPN. If the public uses WebDirect or a website, restrict access only to the Admin Console and APIs under Administration > Restrict Access. Keep Remote Desktop and SFTP or FTPS backup downloads off the open internet.
☐ Turn Off Services You Do Not Use. Under Connectors in the Admin Console, turn off WebDirect, the Data API, OData, ODBC/JDBC, and XML publishing unless they are in use. In Configuration > FileMaker Clients, turn on Filter Databases so outsiders cannot list your files.
☐ Keep FileMaker Server on a Supported Version. Run a version of FileMaker Server that Claris still supports, and install security updates as soon as they’re released. If you run PHP or Custom Web Publishing, patch PHP first. Keep FileMaker Pro, the operating system, web server, plug-ins, and admin tools current too.
☐ Secure Your Admin Console. In Administration > Administrator, change the Admin Console password to a strong, unique one, and change it again whenever someone with access leaves or you suspect it was exposed. Replace your Admin API keys at the same time. If you can, limit Admin Console access to known IP addresses under Administration > Restrict Access.
☐ Check Your Logs for Signs of Access. In the Admin Console, go to Logs > Log Viewer and review the Access log, plus the Admin Console, Data API, and OData logs for any service you run. Bursts of failed logins or repeated attempts from unfamiliar IP addresses mean someone is testing your server, even if no one got in. Then look for anything you didn’t create: Admin API keys under Administration > Administrator and schedules under Configuration > Schedules. Something you didn’t create means someone may have gotten in.
☐ Confirm Your Backups. Keep a current, encrypted backup that an attacker on the server cannot change or delete, and test a restore.
☐ Install a Trusted SSL Certificate. The default FileMaker certificate is for testing only, and without a custom certificate, FileMaker Pro and Go connections to the server aren’t encrypted. In the Admin Console, go to Configuration > SSL Certificate and import a certificate from a trusted authority, or set up Let’s Encrypt for FileMaker Server for a free certificate that renews automatically.
Next: Plan These
☐ Set Up Single Sign-On (SSO) with MFA. Sign in through an identity provider such as Microsoft Entra ID, Okta, or Google to require multi-factor authentication. When someone leaves, disabling one account removes their access everywhere.
☐ Review Older Web Integrations. Older PHP and XML integrations often run on one shared Full Access account. Plan a move to a maintained, least-privilege API connection.
FileMaker Application Configuration Checklist
Critical: Do Today
☐ Turn Off Guest Access and Auto-Login. In File > Manage > Security, uncheck the Guest account. Then, in File > File Options > Open, deselect Log in using. Files are often set to sign in automatically with a default Admin account, the first door attackers try. Need Guest access? Keep public data in a separate file.
☐ Lock Down Every Full Access Account. In File > Manage > Security, remove any Admin account with a blank or default password. Give every Full Access account a strong, unique passphrase, including accounts used for Data API or OData keys, and limit Full Access to a few named people.
☐ Remove Extended Privileges Accounts Do Not Use. In File > Manage > Security > Advanced Security Settings > Extended Privileges, turn off fmrest, fmodata, fmxml, fmxdbc, fmphp, and fmwebdirect wherever they are not needed. Keep fmapp on for FileMaker Pro and Go users.
☐ Set a Minimum Password Length. In File > Manage > Security > Advanced Security Settings > Privilege Sets, edit each custom privilege set and set a minimum password length. Built-in sets like [Full Access] can’t be edited, so move regular users onto custom sets and keep [Full Access] for a few named developers.
☐ Remove Old and Shared Accounts. In File > Manage > Security, delete accounts for former employees, contractors, and vendors, and disable any account no one can identify. Replace shared logins with individual accounts so every user has their own. Each unused account is one more password an attacker can guess, and accounts for people who’ve left are rarely watched.
Next: Plan These
☐ Give Every Account Only the Access It Needs. Build privilege sets on a least-privilege basis, with separate accounts for FileMaker Pro, WebDirect, and each integration.
☐ Enable Encryption at Rest. Encrypted files can’t be opened outside FileMaker, even if someone copies them from the server or a backup.
☐ Keep Secrets Out of Your Files and Logs. Do not store passwords in FileMaker fields or build login systems that look up users in a table. Keep API keys and personal data out of logs and exports.
Short on Time? Start Here
If you only have time for a few things this week, do these five. They close the doors automated attacks try first:
☐ Turn Off Guest Access and Auto-Login in every file.
☐ Lock Down Every Full Access Account with a strong, unique passphrase.
☐ Turn Off Services You Do Not Use in the Admin Console.
☐ Secure Your Admin Console with a new password and new Admin API keys.
☐ Keep FileMaker Server on a supported version, patching PHP first if you run it.
Think Your Server Is Under Attack?
In the Admin Console, enable Block New Users under Configuration > General Settings, disconnect current users, and close the server to external traffic. Then change your passwords, remove any keys, schedules, or accounts you didn’t create, review your logs, and contact your host or our team.
How DB Services Can Help
FileMaker provides strong security controls. Most attacks succeed only when those controls go unused, and the same habits protect every system with a login.
Want a second set of eyes? DB Services can review your servers and applications against these checklists and make the changes for you. Schedule a FileMaker Health Check or contact us for further FileMaker safety assistance.
Rather not manage your own server? DB Services hosts FileMaker for organizations that want updates, security settings, and backups handled by a team that does it every day. Contact us to talk about FileMaker hosting.
