[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fy3xFTp2_54uggDW795fsqSVrlRRvPRXgfbw2R20bw2A":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":26,"hasDownload":27,"fileName":28,"youtubeId":29,"domainCrumb":30,"clusterCrumb":33},"380","D56097C7-8938-A348-9B0E-794E3C3B4F5E","E46BDB0A-2979-1E40-93F7-AC40185848A5","B11BED08-2F4E-4C45-9373-6175FA721411","article","how-to-secure-external-access-to-filemaker-server","How to secure external access to FileMaker Server","A practical guide to safely opening FileMaker Server to remote users, web apps, and APIs — without exposing your business to unnecessary risk.","Your sales team wants to check open orders from their phone during a customer visit. Your warehouse app needs to talk to FileMaker from a browser on the shop floor. A partner company wants a live feed of stock levels through an API. Every one of these is a legitimate business need — and every one of them means someone, somewhere, wants to reach your FileMaker Server from outside your office network.\n\nThat is the exact moment most FileMaker installations go from \"safely tucked behind the office firewall\" to \"exposed to the internet\" — often with far less thought given to it than the business case deserved. This article walks through how to open up external access to FileMaker Server deliberately and safely, instead of accidentally.\n\n## Why is external access to FileMaker Server risky in the first place?\n\nFileMaker Server was originally designed with the assumption that most traffic came from inside a trusted office network. Remote work, mobile field staff, web portals, and API integrations have quietly changed that assumption for almost every business running FileMaker today.\n\nThe risk isn't theoretical. A FileMaker Server reachable from the open internet is a target the same way any database server is: for brute-force login attempts, for outdated SSL certificates that get flagged by browsers and scanners, for unpatched versions with known vulnerabilities, and for poorly scoped accounts that give a compromised laptop far more access than it should ever have.\n\nA concrete example: a wholesale distributor let field reps connect directly to FileMaker Server over the internet using the standard FileMaker client, with the server's IP address hardcoded into a shortcut on each laptop. When one rep's laptop was stolen, the thief had a direct, always-on route into the full customer and pricing database — because the account used a shared password that had never been rotated in three years. Nothing exotic happened technically; a very ordinary laptop theft became a data breach because access controls hadn't kept pace with how the system was actually being used.\n\n## What are the realistic ways people access FileMaker Server externally?\n\nBefore you can secure external access, it helps to be precise about what \"external access\" actually means in your setup, because each path carries different risks:\n\n1. **FileMaker\u002FClaris Pro clients connecting remotely** — staff opening the native client from home or on the road, either directly over the internet or through a VPN.\n2. **WebDirect** — users accessing FileMaker layouts through a browser, no client install required.\n3. **Custom web apps talking to the Data API** — a browser-based portal, a customer-facing app, or an internal web tool (sometimes built with something like FMBetterForms to get a faster, more modern front end than native layouts allow) calling FileMaker Server's REST-style API.\n4. **Third-party or partner integrations** — an accounting package, a webshop, or a logistics partner pulling or pushing data via API connectors.\n5. **AI tools and automation layers** — increasingly, AI assistants or agents that read from or write to FileMaker data to answer questions or trigger workflows, which need their own carefully scoped access path.\n\nEach of these needs a different security posture. A logistics partner's API integration should never have the same access profile as an employee's mobile client, and an AI assistant reading order data should absolutely not be using the same admin-level account your developer uses for schema changes.\n\n## What's the actual step-by-step approach to securing external access?\n\n### 1. Decide who really needs external access — and to what\n\nStart by listing every external access path you currently have, or plan to add, and matching it to a business reason. If nobody can explain why a given account or integration needs external access, it shouldn't have it. This sounds obvious, but in practice most FileMaker systems accumulate access over years, and nobody ever goes back to prune it.\n\n### 2. Put a VPN or reverse proxy in front of direct client access\n\nFor native FileMaker Pro\u002FClaris Pro clients connecting from outside the office, don't expose FileMaker Server's ports directly to the internet. Two solid patterns:\n\n- **VPN**: staff connect to a company VPN first, and only then reach FileMaker Server as if they were on the local network. This is the safer default for internal staff with company-managed devices.\n- **Reverse proxy \u002F gateway**: for scenarios where a full VPN is too heavy (contractors, occasional external partners), a reverse proxy in front of FileMaker Server can terminate SSL, enforce IP allow-lists, and hide the server's real address.\n\nEither way, the server itself should never sit with its FileMaker ports open to \"any\" on the public internet.\n\n### 3. Enforce a valid, current SSL\u002FTLS certificate\n\nEvery external connection — WebDirect, Data API calls, custom web apps — should run over HTTPS with a proper certificate, not the self-signed one FileMaker Server ships with by default. An expired or self-signed certificate trains your own staff to click through security warnings, which is exactly the habit that makes a real phishing attempt succeed later.\n\n### 4. Use FileMaker's own security groups, not shared logins\n\nEvery external user or integration should authenticate as itself, with its own account, in its own privilege set. A shared \"webuser\" account used by both a customer portal and an internal dashboard means you can never revoke access for one without breaking the other, and you lose any meaningful audit trail of who did what.\n\n### 5. Scope API and integration accounts down to exactly what they need\n\nAn account used by a webshop integration to push new orders into FileMaker should be able to create records in the Orders table — and nothing else. It should not be able to see pricing agreements, delete records, or run scripts unrelated to order intake. This is the single most common gap seen in real audits: integration accounts built with full access \"to make development easier,\" and never locked down afterward.\n\n### 6. Rate-limit and monitor API and WebDirect traffic\n\nBrute-force login attempts against exposed WebDirect or Data API endpoints are common and automated — attackers don't need to know you exist, they scan ranges of IP addresses looking for exactly this kind of open door. Rate limiting failed login attempts, and reviewing FileMaker Server's access logs periodically, catches this before it becomes a real incident.\n\n### 7. Keep FileMaker Server and its OS patched\n\nExternal-facing infrastructure should be first in line for patching, not last. A known vulnerability in an old FileMaker Server version, left externally reachable for \"just a few more weeks\" until the next planned maintenance window, is exactly the kind of gap that gets exploited.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F259?w=700&f=webp\" alt=\"layered diagram: internet, firewall, VPN, FileMaker Server, scoped accounts\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n## How does this change when the front end is a custom web app instead of native FileMaker?\n\nMany businesses now put a modern web layer in front of FileMaker Server — for customer portals, mobile-friendly forms, or dashboards — sometimes built with tools like FMBetterForms rather than native FileMaker layouts, precisely because it renders better on phones and browsers.\n\nThis is a genuinely good move for usability, but it shifts where the security responsibility sits. The web app itself becomes a new attack surface: its own login flow, its own session handling, its own server hosting the front end, all sitting between the public internet and your FileMaker Data API. Securing external access in this case means securing two layers, not one — the web app's own authentication and hosting, and the API account it uses to talk to FileMaker Server underneath. A web app with a beautifully secured login screen that calls FileMaker using one shared, over-privileged API key has simply moved the weak point, not removed it.\n\n## Where does AI fit into this, and does it introduce new risk?\n\nAI tools inside a FileMaker workflow — whether that's an assistant answering questions against your data or an agent that automates a task — need their own access path, for the same reasons any integration does. An AI layer that reads order history to answer \"which customers haven't ordered in 90 days\" should have a read-only, scoped account, just like any reporting integration would. The novelty of AI doesn't change the underlying security discipline; it just adds one more consumer of your API that needs to be inventoried, scoped, and monitored like all the others.\n\n## What does a quick self-check look like?\n\n- [ ] Is FileMaker Server's port ever exposed directly to \"any\" IP on the internet? (It shouldn't be.)\n- [ ] Does every remote client connect through a VPN or reverse proxy, not a raw public IP?\n- [ ] Is the SSL certificate valid, current, and not self-signed?\n- [ ] Does every external user or integration have its own account and privilege set — no shared logins?\n- [ ] Are API\u002Fintegration accounts scoped to only the tables and actions they actually need?\n- [ ] Is there a periodic review of which accounts still need external access at all?\n- [ ] Are failed login attempts on WebDirect\u002FAPI endpoints rate-limited and logged?\n- [ ] Is FileMaker Server (and its host OS) on a current, patched version?\n\n## FAQ: securing external access to FileMaker Server\n\n**Is WebDirect inherently less secure than the native client?**\nNot inherently — but because it's browser-based, it's more commonly left reachable from the open internet than a native client would be, so it deserves the same VPN\u002Freverse-proxy and certificate discipline described above.\n\n**Do I need a VPN if all my external access goes through APIs, not the native client?**\nNot necessarily for the API traffic itself, but you still need to protect the server's admin console and any direct client access separately — API access and admin access are different doors that both need locking.\n\n**How often should external access accounts be reviewed?**\nAt minimum every time an employee leaves, a partner contract ends, or an integration is decommissioned — plus a scheduled review, ideally quarterly, to catch accounts nobody remembered to remove.\n\n**Does moving to a custom web front end (like one built with FMBetterForms) make FileMaker Server more or less secure?**\nNeither automatically — it changes the shape of the risk. It can improve security by centralizing and simplifying how users authenticate, but only if the API account behind it is properly scoped rather than given broad access for convenience.\n\nSecuring external access is really one piece of a bigger question: whether your FileMaker solution's overall architecture is still fit for how the business actually works today. If you haven't reviewed that broader picture recently, it's worth reading our guide on [how to improve the performance and structure of a FileMaker solution](https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-improve-the-performance-and-structure-of-a-filemaker-solution) as a next step.\n\nGetting external access right usually isn't a single fix — it's a combination of network setup, account design, and sometimes a rethink of how a web front end or an integration talks to your data. Loggix helps businesses work through exactly this: hardening an existing FileMaker Server setup, building a secure custom web application or API connector on top of it, or simply sitting down together to map out where the real exposure is before it becomes an incident.","\u003Cp>Your sales team wants to check open orders from their phone during a customer visit. Your warehouse app needs to talk to FileMaker from a browser on the shop floor. A partner company wants a live feed of stock levels through an API. Every one of these is a legitimate business need — and every one of them means someone, somewhere, wants to reach your FileMaker Server from outside your office network.\u003C\u002Fp>\n\u003Cp>That is the exact moment most FileMaker installations go from "safely tucked behind the office firewall" to "exposed to the internet" — often with far less thought given to it than the business case deserved. This article walks through how to open up external access to FileMaker Server deliberately and safely, instead of accidentally.\u003C\u002Fp>\n\u003Ch2>Why is external access to FileMaker Server risky in the first place?\u003C\u002Fh2>\n\u003Cp>FileMaker Server was originally designed with the assumption that most traffic came from inside a trusted office network. Remote work, mobile field staff, web portals, and API integrations have quietly changed that assumption for almost every business running FileMaker today.\u003C\u002Fp>\n\u003Cp>The risk isn't theoretical. A FileMaker Server reachable from the open internet is a target the same way any database server is: for brute-force login attempts, for outdated SSL certificates that get flagged by browsers and scanners, for unpatched versions with known vulnerabilities, and for poorly scoped accounts that give a compromised laptop far more access than it should ever have.\u003C\u002Fp>\n\u003Cp>A concrete example: a wholesale distributor let field reps connect directly to FileMaker Server over the internet using the standard FileMaker client, with the server's IP address hardcoded into a shortcut on each laptop. When one rep's laptop was stolen, the thief had a direct, always-on route into the full customer and pricing database — because the account used a shared password that had never been rotated in three years. Nothing exotic happened technically; a very ordinary laptop theft became a data breach because access controls hadn't kept pace with how the system was actually being used.\u003C\u002Fp>\n\u003Ch2>What are the realistic ways people access FileMaker Server externally?\u003C\u002Fh2>\n\u003Cp>Before you can secure external access, it helps to be precise about what "external access" actually means in your setup, because each path carries different risks:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>FileMaker\u002FClaris Pro clients connecting remotely\u003C\u002Fstrong> — staff opening the native client from home or on the road, either directly over the internet or through a VPN.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>WebDirect\u003C\u002Fstrong> — users accessing FileMaker layouts through a browser, no client install required.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Custom web apps talking to the Data API\u003C\u002Fstrong> — a browser-based portal, a customer-facing app, or an internal web tool (sometimes built with something like FMBetterForms to get a faster, more modern front end than native layouts allow) calling FileMaker Server's REST-style API.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Third-party or partner integrations\u003C\u002Fstrong> — an accounting package, a webshop, or a logistics partner pulling or pushing data via API connectors.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>AI tools and automation layers\u003C\u002Fstrong> — increasingly, AI assistants or agents that read from or write to FileMaker data to answer questions or trigger workflows, which need their own carefully scoped access path.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Each of these needs a different security posture. A logistics partner's API integration should never have the same access profile as an employee's mobile client, and an AI assistant reading order data should absolutely not be using the same admin-level account your developer uses for schema changes.\u003C\u002Fp>\n\u003Ch2>What's the actual step-by-step approach to securing external access?\u003C\u002Fh2>\n\u003Ch3>1. Decide who really needs external access — and to what\u003C\u002Fh3>\n\u003Cp>Start by listing every external access path you currently have, or plan to add, and matching it to a business reason. If nobody can explain why a given account or integration needs external access, it shouldn't have it. This sounds obvious, but in practice most FileMaker systems accumulate access over years, and nobody ever goes back to prune it.\u003C\u002Fp>\n\u003Ch3>2. Put a VPN or reverse proxy in front of direct client access\u003C\u002Fh3>\n\u003Cp>For native FileMaker Pro\u002FClaris Pro clients connecting from outside the office, don't expose FileMaker Server's ports directly to the internet. Two solid patterns:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>VPN\u003C\u002Fstrong>: staff connect to a company VPN first, and only then reach FileMaker Server as if they were on the local network. This is the safer default for internal staff with company-managed devices.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Reverse proxy \u002F gateway\u003C\u002Fstrong>: for scenarios where a full VPN is too heavy (contractors, occasional external partners), a reverse proxy in front of FileMaker Server can terminate SSL, enforce IP allow-lists, and hide the server's real address.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Either way, the server itself should never sit with its FileMaker ports open to "any" on the public internet.\u003C\u002Fp>\n\u003Ch3>3. Enforce a valid, current SSL\u002FTLS certificate\u003C\u002Fh3>\n\u003Cp>Every external connection — WebDirect, Data API calls, custom web apps — should run over HTTPS with a proper certificate, not the self-signed one FileMaker Server ships with by default. An expired or self-signed certificate trains your own staff to click through security warnings, which is exactly the habit that makes a real phishing attempt succeed later.\u003C\u002Fp>\n\u003Ch3>4. Use FileMaker's own security groups, not shared logins\u003C\u002Fh3>\n\u003Cp>Every external user or integration should authenticate as itself, with its own account, in its own privilege set. A shared "webuser" account used by both a customer portal and an internal dashboard means you can never revoke access for one without breaking the other, and you lose any meaningful audit trail of who did what.\u003C\u002Fp>\n\u003Ch3>5. Scope API and integration accounts down to exactly what they need\u003C\u002Fh3>\n\u003Cp>An account used by a webshop integration to push new orders into FileMaker should be able to create records in the Orders table — and nothing else. It should not be able to see pricing agreements, delete records, or run scripts unrelated to order intake. This is the single most common gap seen in real audits: integration accounts built with full access "to make development easier," and never locked down afterward.\u003C\u002Fp>\n\u003Ch3>6. Rate-limit and monitor API and WebDirect traffic\u003C\u002Fh3>\n\u003Cp>Brute-force login attempts against exposed WebDirect or Data API endpoints are common and automated — attackers don't need to know you exist, they scan ranges of IP addresses looking for exactly this kind of open door. Rate limiting failed login attempts, and reviewing FileMaker Server's access logs periodically, catches this before it becomes a real incident.\u003C\u002Fp>\n\u003Ch3>7. Keep FileMaker Server and its OS patched\u003C\u002Fh3>\n\u003Cp>External-facing infrastructure should be first in line for patching, not last. A known vulnerability in an old FileMaker Server version, left externally reachable for "just a few more weeks" until the next planned maintenance window, is exactly the kind of gap that gets exploited.\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F259?w=700&f=webp\" alt=\"layered diagram: internet, firewall, VPN, FileMaker Server, scoped accounts\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch2>How does this change when the front end is a custom web app instead of native FileMaker?\u003C\u002Fh2>\n\u003Cp>Many businesses now put a modern web layer in front of FileMaker Server — for customer portals, mobile-friendly forms, or dashboards — sometimes built with tools like FMBetterForms rather than native FileMaker layouts, precisely because it renders better on phones and browsers.\u003C\u002Fp>\n\u003Cp>This is a genuinely good move for usability, but it shifts where the security responsibility sits. The web app itself becomes a new attack surface: its own login flow, its own session handling, its own server hosting the front end, all sitting between the public internet and your FileMaker Data API. Securing external access in this case means securing two layers, not one — the web app's own authentication and hosting, and the API account it uses to talk to FileMaker Server underneath. A web app with a beautifully secured login screen that calls FileMaker using one shared, over-privileged API key has simply moved the weak point, not removed it.\u003C\u002Fp>\n\u003Ch2>Where does AI fit into this, and does it introduce new risk?\u003C\u002Fh2>\n\u003Cp>AI tools inside a FileMaker workflow — whether that's an assistant answering questions against your data or an agent that automates a task — need their own access path, for the same reasons any integration does. An AI layer that reads order history to answer "which customers haven't ordered in 90 days" should have a read-only, scoped account, just like any reporting integration would. The novelty of AI doesn't change the underlying security discipline; it just adds one more consumer of your API that needs to be inventoried, scoped, and monitored like all the others.\u003C\u002Fp>\n\u003Ch2>What does a quick self-check look like?\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Is FileMaker Server's port ever exposed directly to "any" IP on the internet? (It shouldn't be.)\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Does every remote client connect through a VPN or reverse proxy, not a raw public IP?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Is the SSL certificate valid, current, and not self-signed?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Does every external user or integration have its own account and privilege set — no shared logins?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Are API\u002Fintegration accounts scoped to only the tables and actions they actually need?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Is there a periodic review of which accounts still need external access at all?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Are failed login attempts on WebDirect\u002FAPI endpoints rate-limited and logged?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Is FileMaker Server (and its host OS) on a current, patched version?\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>FAQ: securing external access to FileMaker Server\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Is WebDirect inherently less secure than the native client?\u003C\u002Fstrong>\nNot inherently — but because it's browser-based, it's more commonly left reachable from the open internet than a native client would be, so it deserves the same VPN\u002Freverse-proxy and certificate discipline described above.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Do I need a VPN if all my external access goes through APIs, not the native client?\u003C\u002Fstrong>\nNot necessarily for the API traffic itself, but you still need to protect the server's admin console and any direct client access separately — API access and admin access are different doors that both need locking.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>How often should external access accounts be reviewed?\u003C\u002Fstrong>\nAt minimum every time an employee leaves, a partner contract ends, or an integration is decommissioned — plus a scheduled review, ideally quarterly, to catch accounts nobody remembered to remove.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Does moving to a custom web front end (like one built with FMBetterForms) make FileMaker Server more or less secure?\u003C\u002Fstrong>\nNeither automatically — it changes the shape of the risk. It can improve security by centralizing and simplifying how users authenticate, but only if the API account behind it is properly scoped rather than given broad access for convenience.\u003C\u002Fp>\n\u003Cp>Securing external access is really one piece of a bigger question: whether your FileMaker solution's overall architecture is still fit for how the business actually works today. If you haven't reviewed that broader picture recently, it's worth reading our guide on \u003Ca href=\"https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-improve-the-performance-and-structure-of-a-filemaker-solution\">how to improve the performance and structure of a FileMaker solution\u003C\u002Fa> as a next step.\u003C\u002Fp>\n\u003Cp>Getting external access right usually isn't a single fix — it's a combination of network setup, account design, and sometimes a rethink of how a web front end or an integration talks to your data. Loggix helps businesses work through exactly this: hardening an existing FileMaker Server setup, building a secure custom web application or API connector on top of it, or simply sitting down together to map out where the real exposure is before it becomes an incident.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901677000,[19,20,21,22,23,24,25],"FileMaker Server security","external access","VPN vs reverse proxy","FMBetterForms","API security","FileMaker hosting","Claris FileMaker","\u002Fapi\u002Fknowledge\u002Fimage\u002F380\u002F?v=b65782588418",false,"",null,{"title":31,"slug":32},"FileMaker and Claris","filemaker-and-claris",{"title":34,"slug":35},"How to improve the performance and structure of a FileMaker solution","how-to-improve-the-performance-and-structure-of-a-filemaker-solution"]