Your FileMaker Server is being scanned right now

If your FileMaker Server has a public IP address, it is being probed by automated scanners. Not occasionally: continuously, by bots that never sleep and never get bored. Many of them are now AI-assisted, which means they adapt to what they find rather than running a fixed script.

For years, FileMaker systems enjoyed a kind of security through obscurity. Attackers focused on WordPress, Exchange and SQL Server, and few bothered to learn how a FileMaker Server works. That protection has gone. The Data API, OData and WebDirect have made FileMaker Server a standard web-facing service, and large language models have made it trivial for anyone to ask "how do I enumerate and brute-force a FileMaker Server?" and get a working answer in seconds.

This guide explains how modern automated attacks target FileMaker Server, gives you a one-minute check you can run today, and lists the ten configuration changes that close the most common gaps. It is written for business owners, IT managers and in-house developers who run FileMaker but are not security specialists.

If you would rather have someone else do the checking, Neptune Digital offers a free FileMaker PHP security audit and a full 100-point FileMaker Health Check. Details are at the end.

How AI-assisted attacks target FileMaker Server

An automated attack on a FileMaker Server rarely starts with a person. It starts with a scanner that works through the internet address by address, and it follows a predictable sequence.

1. Discovery. The bot finds a server listening on port 443 or 5003 and recognises the FileMaker Server fingerprint from its response headers and login pages. Search engines for internet-connected devices such as Shodan and Censys index these fingerprints, so an attacker can also just search for "FileMaker Server" and get a ready-made target list.
2. Enumeration. The bot asks the server what it hosts. If the Data API or WebDirect publishes a list of databases without a login, the attacker now has every file name. If it does not, the bot guesses common ones: Contacts, CRM, Jobs, Invoices.
3. Credential guessing. For each file, the bot tries default and common accounts: admin, Admin, fmsadmin, filemaker, test, guest, with blank, simple and leaked passwords. It spreads attempts across files and time to stay under lockout thresholds.
4. Access and persistence. With one working login, the attacker reads data through the Data API or OData, exports it, and may create a new account or disable others. Ransom demands and data-sale listings follow.

What has changed with AI is steps 2 and 3. A traditional script runs a fixed word list. An AI-assisted scanner reads the error messages it gets back, infers the FileMaker version, adjusts its approach, and generates plausible file and account names from the company's own website. It is cheaper and more patient than a human attacker, and it never gives up on a target that looks promising.

The defence is not complicated. It is about removing the information the bot relies on at steps 1 and 2, and making step 3 impossible rather than merely slow.

The open door: the Data API database list

The single most useful thing you can give an attacker is a list of what to attack. FileMaker Server will hand that over through one URL if it is left on its development-friendly defaults.

The FileMaker Data API has an endpoint that lists the databases hosted on a server:

https://your-server/fmi/data/vLatest/databases

Depending on how the server is configured, this endpoint answers without any login. The bot finds your server, requests the list, and starts guessing passwords against every file it gets back. It no longer has to guess file names, which removes most of the work from the attack.

The same information can leak through other routes:

• The WebDirect launch page, which can list all WebDirect-enabled files with their icons.
• The FileMaker Pro hosts dialog, which lists every open file on the server unless filtering is enabled.
• The OData service root, which lists exposed databases to any caller with a valid token.

None of these is a bug. They are defaults chosen for a developer on a trusted office network, and they are the wrong defaults for a server that anyone on the internet can reach.

The one-minute FileMaker security check

Open the Data API databases URL for your own server in a private browser window, without logging in to anything:

https://your-server/fmi/data/vLatest/databases

• A login error (HTTP 401) means the list is protected. Good.
• A JSON list of file names means anyone on the internet can read it too, and your server is a soft target.

Then try the WebDirect page at https://your-server/fmi/webd and the hosts list from a copy of FileMaker Pro that has never connected to your server. If either shows files you did not expect to be public, you have more to close.

These checks take a minute and are entirely safe to run against your own server. If the results surprise you, the next section tells you what to change.

Ten ways to harden FileMaker Server against automated attacks

Work through these in order. The first five close the database list and stop password guessing; the rest reduce what an attacker can do if they ever get in.

1. Filter the database list. Admin Console → Configuration → FileMaker Clients → Filter databases in Client Application → Enabled. This is on by default, so the job is to confirm nobody switched it off. With filtering on, a client only sees files it can open.
2. Require a login for the Data API list. Run this on the server:

   fmsadmin set serverprefs DenyGuestAndAutoLogin=true

   Check first: this disables Guest access and automatic login for every file on the server. Any file that relies on a Guest account or a stored credential will stop opening until you fix it, which is usually a good thing.
3. Remove the Data API privilege from files that don't need it. In each file, open Manage Security → Privilege Sets and untick Access via FileMaker Data API (fmrest) for every privilege set that does not use it. Do the same for fmwebdirect and fmodata. A file that cannot be reached by an API cannot be attacked through it.
4. Rename or delete the admin account. It is the first name every bot tries. The same goes for fmsadmin, filemaker, test and guest. Full-access accounts should have unguessable names and long passphrases, and there should be as few of them as possible.
5. Restrict the Data API and OData by IP address. If only a handful of integrations use your APIs, allow only their addresses through the firewall or the server's own reverse proxy. Everyone else gets nothing. For WebDirect and FileMaker Pro clients who need access from anywhere, put them behind a VPN or require SSO.
6. Turn on SSO or external authentication. FileMaker Server supports OAuth with Microsoft Entra ID, Google and Okta, and Active Directory through external groups. Centralised identity means multi-factor authentication, password policies and instant offboarding, none of which FileMaker's internal accounts give you.
7. Keep the server and the files up to date. Claris releases security fixes with each version. Running a FileMaker Server more than two versions behind means running known vulnerabilities. If you are on an old on-premise box, read our guide to migrating legacy FileMaker to the cloud.
8. Use a real SSL certificate and disable old TLS. A self-signed certificate trains users to click through warnings and tells scanners the server is unmaintained. Use a certificate from a public CA and turn off TLS 1.0 and 1.1 in the Admin Console.
9. Review every file's privilege sets. Over the years, "temporary" full-access accounts accumulate. Audit who can export, who can modify schema and who can run scripts with full access. Remove what is not needed. Our FileMaker security and UK GDPR checklist covers this in detail.
10. Log, monitor and back up off-server. Enable the Admin Console's access log, send it somewhere you will actually look, and keep backups on a different machine. Lockout protection stops a brute-force attack; the log is how you find out it happened; the backup is how you recover if something gets through.

Most of these take under an hour. Together they turn your server from one of the easiest targets on a scanner's list into one of the hardest.

The forgotten risk: legacy FileMaker PHP sites

Many FileMaker Servers still run a customer portal, booking form or staff intranet built years ago on the FileMaker PHP API (Custom Web Publishing). These sites are often the most exposed part of the whole system, and the least looked at.

The PHP API has been deprecated by Claris and is no longer actively maintained. Sites built on it typically share three problems:

• Credentials in plain text. The FileMaker account name and password sit in a PHP config file on the web server. Anyone who can read that file, through a misconfigured directory listing or an outdated PHP vulnerability, owns your database.
• Over-privileged accounts. The web account was often given more access than the site needed because it was quicker at the time. A simple contact form may be running on an account that can read every table.
• Unpatched PHP and web server. The PHP version the site was built on is frequently years out of support, with publicly known exploits that scanners test for automatically.

Because these sites are reached over standard HTTP, they are found by the same scanners that look for vulnerable WordPress and Joomla installs. They are a far easier way into a FileMaker system than the FileMaker Server itself.

Neptune Digital offers a free FileMaker PHP security audit. We review your PHP site's configuration, the account it uses, the PHP and web server versions, and how it talks to FileMaker Server, and we give you a written list of findings with a recommended fix for each. There is no charge and no obligation. If the sensible answer is to rebuild on the Data API or WebDirect, we will say so and tell you what it would cost.

Request your free PHP audit through our contact page or email hello@neptunedigital.co.uk.

Warning signs your server is being probed

Attacks rarely announce themselves, but FileMaker Server leaves clues. Check the Admin Console and the access log for:

• Repeated failed logins for accounts that don't exist, especially admin, fmsadmin and filemaker.
• Failed Data API or OData requests from IP addresses you don't recognise, often in bursts late at night UK time.
• Accounts locked out by lockout protection when nobody in the business was trying to log in.
• New accounts, new privilege sets or changed passwords that nobody remembers creating.
• Unusual export or script activity outside business hours.
• A sudden rise in CPU or network traffic on the server with no change in user numbers.

Any one of these on its own may be nothing. Two or more together mean someone is working on your server, and it is time to act.

What a full FileMaker security audit covers

The ten fixes above deal with the server. A proper audit also looks inside the files, at the people who use them and at the processes around them. Neptune Digital's FileMaker Health Check is a 100-point review, and its security section covers:

The Health Check is priced from £920 to £8,280 depending on the number of files and the depth required. You receive a written report with every finding rated by severity, a prioritised fix list and an estimate for each fix. Roughly half of our work is on systems other people built, so there is no judgement, only a plan.