FileMaker Security: Best practices you should be incorporating in your solutions.

Today, lets talk security. How can you make sure your data or your client’s data is secure on the FileMaker platform?

As developers and business owners, we should be doing our best to ensure that our intellectual data and our clients intellectual data is safe and secure in our systems.

While FileMaker does have security features in place from the get-go to protect access to your solutions, it’s easy to leave open some back doors and be unaware how available your solution might be.

I’m going to share some best practices that will help tighten down the security of your solution and give you some ease-of-mind that your data is safe behind locked doors.

Tip #1 — Passwords

Let’s start with the basics. Passwords. This is the most fundamental piece of security you should address with your solution.

Here are some statistics about passwords that may cause you to think twice about how you’re using yours:


Now that I’ve given you the scary stuff, let’s see improve our password practices.

Remove that Admin login!

By default, new FileMaker Solutions are set up with an Admin [Full-Access] account to get you started in your development, but is never intended to stay. Even scarier, it has no password!

I’ve worked with too many clients who have been using this login for the entire company for years on their solution! [Cries in developer].

As soon as you start development, replace this account with your own [Full Access] developer account. Make sure you provide a unique hard-to-guess username, that is secured with a strong password. No “1234” or “password” passwords! I’ll talk about strong passwords below.

Once you have created your new [Full Access] account, delete that Admin account entirely. You are required to have a least one active [Full Access] account before you can delete the original Admin account.

Pro-Tip: You can remove all [Full-Access] accounts entirely using the Developer Tools. This is a great option for completely removing that access when you deploy a build.

Strong Passwords

Strong Password

What makes a password strong? There are some good rules of thumb to use when creating your passwords to ensure they are strong.

  1. Password Length — The longer the password, the longer it will take password crackers to brute force their way in. I’d recommend using a password at least 12 characters in length. Personally, I used 20–25 character passwords.
  2. Avoid Actual Words — Attackers will try to use dictionaries to guess passwords, even if you change an E for a 3 or an O for a 0 (zero), there’s a good chance they will brute force guess your word at some point.
  3. Use lowercase letters, uppercase, letters, numbers, and symbols — By using all types of characters in your password, you will make it even harder to guess by malicious attacks.
  4. Rotate your passwords ever few months — It is a good idea to change your passwords over time in. If someone ever gets an old password, you won’t have to worry about it allowing them unauthorized access if you changed it a few months ago.
  5. Don’t use the same password twice or across different services/sites. If you have a unique password to each site you login to, solution you access, or service you subscribe to, you are protected if any one password gets leaked. If you use the same password for everything, you’re going to have a long day ahead of you to update all your logins after a breach.

With the above rules, you can create trillions of unique passwords that won’t be guessable by hackers or malicious bots.

Pro-Tip: Use a software like LastPass or 1Password to track your complex passwords. I personnally use Last Pass (Free) on browser and mobile to store and track a unique password for everything!

Tip #2 — Utilize Privilege Sets!

How can we enforce strong passwords for our users? Privilege Sets.

Enforce Strong Passwords for FileMaker Users

Under the FileMaker Security, we can enforce some constraints to our users for new accounts. Unfortunately, it doesn’t allow for rules like using complex characters/symbols, but we can set up a minimum password length as well as require a password to be changed every X days.

Under FileMaker → Manage Security, we can set up Privilege Set rules to allow users to change their password as well as require some rules for their passwords.

This will ensure your users will be following good password practices while they have access to your solution. Note, you will have to set this up with every privilege set if your solution has multiple tiers of privileges.

Utilize Data Access and Design under Privilege Sets

To continue off assigning password rules for users, we also have the ability to control Data Access based on privileges. Perhaps you have users who are only allowed to View data, but should not be allowed to Edit or Delete data.

Create specific privilege sets for users based on how much data access and privileges they should have.

Under the Data Access and Design, we have the ability to control Record access, layout access, value list access, and script access.

Record Access — Allows us to specify which tables and fields users can Create/Edit/View/Delete data from.

Layout Access — Allows us to specify what interfaces of the solution users can view or modify, as well as if they can view or modify records through this layout.

Value Lists Access — Allows us to control modification or use of value lists in the solution. Sometimes we may allow an office manager to add new options to a value list, but a sales employee may only be able to use the specified values.

Scripts Access — Allows us to control scripting that users can run and/or modify. With this we can turn of scripts that users should not be able to run to manipulate data unintentionally.

I suggest reviewing each of these areas and reading more about Privilege Sets in FileMaker’s documentation to determine how you can best use these options to secure your data to authenticated users.

FileMaker 18 — About Accounts, Privilege Sets, and External Privileges

With FileMaker adding new ways to access your FileMaker Data, it is important to make sure that your Extended Privileges are set up to only allow access through the technologies you use.

Extended Privileges

Extended privileges are how we control access through third party connections like ODBC, FileMaker GO, WebDirect, Custom Web Publishing, and the FileMaker Data API.

This interface is pretty straight forward. You will toggle any extended privilege you want to provide access to your solution with. Anything not toggled will not be able to get in, even if they have a password to your solution.

Tip #3 — Firewalls!

Assuming you have your solution hosted on FileMaker Server or Cloud, you should only allow access through your server’s firewall on minimal ports.

Most firewalls are pretty good about locking down to the bare minimum, but for good measure, you should only allow access through the following ports for FileMaker Server.

Now, if you don’t utilize ODBC/JDBC, you probably should just close that port.

If you want to be extra secure, you could always limit port access to specific IP ranges. This is a good way to ensure that you aren’t allowing remote access into your solution.

I won’t get into the details on the IT side, so I would recommend talking with your IT Service Provider to make sure your firewall is secure. You may even want to discuss utilizing a VPN product to add an additional layer of authentication to get into your network.

Tip #4 — Server-Side Encryption (SSL)

Now let’s talk about data that’s being transmitted over the WAN for your solutions. With companies becoming more remote and building WebDirect and Custom Web integrations for their FileMaker data, it is extremely important to protect data being transmitted between your FileMaker Server and any FileMaker Clients or third-party services connecting to your data.

This is handled by installing an SSL certificate on your FileMaker Server.

You can read more about how to order and install and SSL certificate through FileMaker’s documentation.

FileMaker Network Security and Supported SSL

Important — Make sure you purchase from an SSL provider that FileMaker has confirmed compatibility with. This will help to avoid headaches down the road.

Tip #5 — Database Encryption

This is a more advanced tip that requires you to take down your solution to set up. Using FileMaker’s Developer Utilities, we can require an encryption password for our database files so that if they are opened locally, we have a 2nd layer of authentication to get through. This is helpful for offline backups you may store.

  1. Under Tools → Developer Utilities, add local FileMaker solution(s) to the dev tools.
  2. Select your project folder to write the copies to.
  3. Under Solution Options, check the box to Enable Database Encryption.
  4. Provide your [Full Access] Login.
  6. Press Ok.
  7. Press Create.

You should now have an encrypted local copy of your solution. As you can see below, if I try to open the file locally with FileMaker Pro, I have to enter the encryption password before I can log in.

This protects your solution in a scenario that an attacker gets a copy of your FileMaker Solutions and tries to access them offline on their own machine.

Additional Resources:

Steven Blackwell has a great white paper about FileMaker Security that you can download here:

FileMaker 18 Security Features

FileMaker Platform Security Overview

Using the above features are a great way to get started in securing your FileMaker Data.

If you have any questions or comments, do not hesitate to reach out to me. Let me know what FileMaker topics you would like to hear more about next!





Software Developer and Code Ninja

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Story of a 2.5k Bounty — SSRF on Zimbra Led to Dump All Credentials in Clear Text

Top 10 Best Phone Tracker Apps in 2021

Vulnhub: Potato Walkthrough

Six Google Alternative Search Engines

Free Fire codes today March 6, 2022; All free rewards

When you hear the word authenticator or authentication, you may think this is only a technology…

Work-Life balance in Information Security Industry

Security & Transparency: Minted Vodka NFT Exchange has been audited

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jeffrey Henry

Jeffrey Henry

Software Developer and Code Ninja

More from Medium

Angular/React — Public client Single Page Applications — a secure practice on where to store the…

Managing cold chain IoT data security — Intertrust Technologies

How to distinguish private, public and protected in java