Wim Decorte, Claris Engage 2024
- Introduction: Why Security Is More Important Than Ever
- Key Domains of Security in FileMaker
- Addressing Common FileMaker Security Weak Points
- Strengthening Authentication and Authorization
- Record-Level Access Control and Performance Considerations
- Data Encryption: A Must-Have for Modern FileMaker Solutions
- Plugins and File Access Protection
- Monitoring and Auditing: The Power of Logs
- Offboarding Users and Managing Access Lifecycle
- Conclusion: Prioritizing Security in Your FileMaker Development Process
As the complexity of digital ecosystems continues to evolve, ensuring the security of the applications we build has never been more important. With the increasing sophistication of attacks, even a small oversight can lead to catastrophic results such as data breaches, fines, or damage to reputation. This blog post delves deep into FileMaker security, examining the specific challenges faced by developers and administrators, and detailing the best practices and tools available within FileMaker to protect your solutions. Inspired by a presentation at Claris Engage 2024, this comprehensive guide is designed to help you bolster your FileMaker security and build resilient, secure applications.
Why Security Is More Important Than Ever
In today’s connected world, security is non-negotiable. Any digital system is vulnerable to attacks, and as developers, our responsibility is to protect the sensitive data and assets of our clients. Failure to do so can lead to:
- Financial Losses: Downtime due to an attack or data breach can cause significant financial repercussions for businesses, both from lost productivity and the potential fines from regulatory bodies.
- Data Breaches: Sensitive client information, financial records, or confidential documents can be exposed or stolen, with far-reaching consequences, especially if this data falls under privacy laws like the General Data Protection Regulation (GDPR).
- Reputation Damage: Even a single data breach can tarnish the reputation of a business or its developer, leading to a loss of clients and trust.
- Legal and Regulatory Penalties: Non-compliance with security standards, such as NIS2 or GDPR, can result in hefty fines. Regulatory requirements are becoming stricter, and organizations that fail to meet these standards will face increasing penalties.
In short, security is not just about protecting data—it’s about safeguarding your clients’ operations, legal standing, and your own reputation as a developer.
Key Domains of Security in FileMaker
Security can be broadly divided into several critical domains, each addressing different types of risks and threats. As a FileMaker developer or administrator, it’s essential to understand these domains and how they intersect with your work.
1. Information Security (Infosec)
Infosec is concerned with the control and dissemination of data. This involves ensuring that sensitive information is only accessible to authorized users and protecting that data from being improperly shared or leaked. With the growing popularity of AI models and data analytics, it’s important to consider how sensitive data is processed. AI models, particularly large language models (LLMs), can introduce security risks if they are allowed access to sensitive or confidential data.
- AI Sec: AI security (AI Sec) has become a subset of infosec, as data processed through AI systems can pose a significant risk if mishandled. Sending proprietary or confidential data to a third-party AI service can expose vulnerabilities, especially if the service provider is not under your control or does not provide clear data usage guidelines. Developers should carefully evaluate whether data can be shared with such services or consider hosting AI systems internally to maintain better control over the data lifecycle.
2. Operational Security (OpSec)
OpSec focuses on protecting the physical systems that store and process data, such as servers, computers, and network devices. Physical security measures can include controlling access to servers, preventing tampering, and mitigating risks like firmware vulnerabilities or physical hardware hacks. For example, if your FileMaker Server is physically accessible by unauthorized personnel, your system could be vulnerable to attacks at the hardware or firmware level.
While OpSec is often managed by IT departments, developers need to be aware of these risks, especially when working on-premise solutions or in environments with lax physical security controls. Consider working with your client’s IT teams to ensure that servers and critical infrastructure are adequately secured, from locked server rooms to ensuring that firmware is up-to-date and free from known vulnerabilities.
3. Network Security (NetSec)
Network security is critical for protecting data as it travels over networks. This domain encompasses securing routers, switches, firewalls, and encrypting the data in transit. Encryption in transit ensures that data cannot be intercepted and read by unauthorized parties while it’s being transmitted between clients, servers, or external networks. Developers should ensure that data is always transmitted securely, using SSL certificates and VPNs to protect sensitive information from being exposed during transit.
In a FileMaker context, SSL certificates are crucial for encrypting communication between FileMaker Pro, FileMaker Go, WebDirect, and FileMaker Server. Using these certificates prevents attackers from performing man-in-the-middle attacks or intercepting data as it moves between components of the FileMaker solution.
4. Application Security (AppSec)
Application security is where developers have the most control. AppSec deals with protecting the actual software from vulnerabilities that could be exploited by attackers. This includes everything from securely handling user authentication to ensuring that proper authorization controls are in place.
In FileMaker, application security revolves around using built-in tools such as privilege sets, extended privileges, record-level access control, and custom security models. The goal is to ensure that unauthorized users cannot access sensitive data or execute unauthorized actions. Developers need to stay vigilant about closing loopholes that could be used by malicious actors, such as full access privileges on scripts, or bypassing default security mechanisms through poorly configured settings.
Application security should be designed and tested throughout the development lifecycle, not left as an afterthought. As we will see later, failing to implement robust AppSec practices can lead to severe vulnerabilities that can be exploited in minutes.
Addressing Common FileMaker Security Weak Points
There are several weak points in FileMaker security that developers must actively address to protect their solutions. Some of these vulnerabilities stem from the default settings in new FileMaker files, while others arise from common developer practices that inadvertently create security holes.
1. Default Insecurity in New Files
When a new FileMaker file is created, it is not secure by default. The file is automatically configured to allow auto-login with full access privileges. While this may simplify the development process, it is extremely dangerous in a production environment. Auto-login with full access gives any user unrestricted control over the entire system, including the ability to modify or delete data, change schema, or run scripts with no limitations.
To secure a new file, developers should:
- Disable auto-login: Ensure that the default “Admin” account is removed or locked and require users to authenticate using properly configured accounts.
- Set a minimum version requirement: The default minimum version is set to FileMaker Pro 12. Given the security vulnerabilities in older versions, developers should raise this minimum to the latest version of FileMaker. This ensures that only clients using secure, up-to-date versions of the platform can access the file.
2. Ersatz Security Systems and Custom Security Schemes
Developers sometimes create their own security systems within FileMaker, assuming they can build something more flexible or intuitive than the built-in security model. This is rarely true. Custom security systems that attempt to bypass FileMaker’s built-in security schema often introduce significant vulnerabilities.
Common examples of insecure custom security systems include:
- User tables with manual control over access levels, which can easily be manipulated by savvy users or attackers.
- Scripts that manage security checks based on UI elements, such as buttons or layouts, which can be bypassed if the user knows how to manipulate FileMaker’s internal structure.
FileMaker’s native security system is far more robust than any custom solution. By default, privilege sets enforce role-based access control (RBAC), ensuring that users are only given the minimum level of access they need to perform their tasks. Developers should use FileMaker’s built-in security system rather than trying to reinvent the wheel.
3. Overusing Full Access Privileges
One of the most common security mistakes developers make is granting full access privileges to scripts. When a script is granted full access, it runs with the highest level of privilege in the system, bypassing the user’s normal security restrictions. This can create serious vulnerabilities if the script is not properly controlled or if the developer forgets to remove full access after troubleshooting.
For example, a script designed to allow a manager to generate reports might be granted full access to bypass permission issues. However, if this script is later accessed by an unauthorized user, it could allow them to perform actions outside of their normal permissions, such as deleting records or exporting sensitive data.
To mitigate this risk:
- Limit the use of full access privileges: Only use full access when absolutely necessary, and ensure that it is removed once the task is completed.
- Regularly audit scripts: Periodically review scripts in your solution to identify those that have been granted full access privileges, and confirm that they are still necessary.
4. Failure to Use Custom Extended Privileges
FileMaker allows for granular control over what users can do within the system, thanks to extended privileges. However, many developers overlook this powerful feature, relying solely on default privileges. Custom extended privileges allow you to define specific actions that users can perform, such as whether they can export data, print records, or interact with external systems via APIs.
For example, you might create custom extended privileges for:
- “Approve Invoices”: A privilege that allows a user to approve invoices but not create or modify them.
- “Generate Reports”: A privilege that permits report generation but blocks data export.
By leveraging extended privileges, you can create a zero-trust environment, where users only have access to specific functionality at the time it is needed, rather than granting them blanket permissions. You can also use custom extended privileges in your scripts to verify whether a user has the necessary rights before performing an action, adding an extra layer of security.
Strengthening Authentication and Authorization
Authentication and authorization are the two pillars of access control in any digital system. Authentication is the process of verifying the identity of a user, while authorization determines what that user is allowed to do once they are authenticated. In FileMaker, developers have several options for managing both.
Internal Authentication vs. External Authentication
FileMaker provides two main types of authentication: internal accounts (stored within the FileMaker file) and external authentication (using identity providers such as OAuth, Active Directory, or custom OAuth 2.0 providers).
Internal Authentication
Internal authentication is the default method in FileMaker, where users log in with credentials stored directly in the FileMaker file. While this is convenient for smaller solutions, it can become difficult to manage as the number of users grows. Additionally, internal authentication is vulnerable to brute force attacks if proper password policies are not enforced.
External Authentication
External authentication shifts the responsibility for identity management to a third-party identity provider, such as Google, Microsoft Azure AD, or Okta. These providers typically offer more advanced security features, such as multi-factor authentication (MFA), passwordless login, and context-based access.
External authentication is preferred for larger organizations or high-security environments because:
- It removes the need for developers to manage user credentials, reducing the risk of mishandling sensitive information.
- Identity providers often provide built-in monitoring, auditing, and reporting features to track login activity, failed login attempts, and security threats.
- External authentication can also support single sign-on (SSO), allowing users to authenticate once and gain access to multiple systems, including FileMaker.
Authentication Order and Priority
In cases where users are part of multiple groups, FileMaker uses an authentication order to determine which privilege set to apply. This is often overlooked but can lead to unintended privilege assignments if not properly managed. Be sure to carefully order the priority of user groups to ensure that users get the correct level of access based on their roles.
Preventing Single-Form Authentication
Single-form authentication (username and password) is the most basic form of authentication but also one of the most vulnerable. Without additional safeguards, single-form authentication is susceptible to brute force attacks and dictionary attacks, where hackers systematically guess passwords to gain access.
To mitigate this risk:
- Implement multi-factor authentication (MFA) wherever possible. MFA requires users to provide an additional piece of information (such as a code sent to their phone) beyond their password, making it much more difficult for an attacker to break in.
- Use external identity providers that support advanced authentication techniques, such as contextual authentication (where the system takes into account the user’s location, device, and behavior) to further strengthen security.
Securing Passwords with Encryption
FileMaker doesn’t store user passwords directly. Instead, it stores hashes of passwords, which are one-way encrypted versions of the original password. Even if an attacker gains access to the file, they cannot retrieve the actual passwords. However, encryption at rest adds an additional layer of security by preventing unauthorized users from accessing the hashed passwords in the first place.
Cracker tools available online claim to reveal FileMaker passwords, but they do so by tampering with the file and disabling authentication, rather than by revealing the passwords themselves. Enabling encryption at rest will block these tools, as they cannot decrypt the file to modify it.
Record-Level Access Control and Performance Considerations
One of FileMaker’s most powerful security features is record-level access control, which allows developers to define granular rules for which records a user can access based on a calculation. This is particularly useful in multi-tenant solutions, where different users or groups need to see different subsets of data. For example, you can limit a salesperson’s access to only the records related to their own accounts, or restrict access to financial data based on job roles.
However, record-level access control comes with a performance cost. FileMaker must evaluate the access calculation for every record the user attempts to view, which can slow down the system, especially when large datasets are involved.
How to Minimize Performance Impact
- Keep Calculations Simple: The simpler your record-level access calculations, the faster FileMaker can evaluate them. Avoid complex logic or heavy dependencies on related records when defining access control calculations.
- Avoid Large Record Sets: Showing thousands of records in a list view forces FileMaker to evaluate access control for each one, which can degrade performance. Instead, limit the number of records displayed to the user at any given time. For example, use filters or search constraints to reduce the initial dataset before applying access rules.
For example, in one case involving 100,000 records, a basic record-level access calculation added a fraction of a second to the layout rendering time. While this is acceptable in small datasets, more complex calculations or larger datasets could significantly impact performance.
Data Encryption: A Must-Have for Modern FileMaker Solutions
Encryption is one of the most critical security tools in any digital system, and FileMaker provides both encryption at rest and encryption in transit. These two forms of encryption work together to ensure that data is always protected, whether it’s stored in a file or being transmitted across networks.
1. Encryption at Rest
Encryption at rest ensures that data stored in a FileMaker file is encrypted when the file is not in use. This protects against unauthorized access to data if the file is copied or stolen. For example, if someone gains physical access to a backup of the database, they would not be able to read the data without the encryption key.
How to Enable Encryption at Rest:
- Use FileMaker’s Developer Tools or the command-line interface to encrypt your files.
- Ensure that all backups are encrypted, which is done automatically if encryption at rest is enabled for the live database.
Benefits of Encryption at Rest:
- Protects against unauthorized access to data in the event that the file is stolen or copied.
- Prevents cracker tools from disabling authentication or accessing password hashes.
- Ensures that backup files are secure, even if they are stored offsite or in the cloud.
2. Encryption in Transit
Encryption in transit protects data while it is being transmitted between different components of the FileMaker solution (e.g., between FileMaker Pro and FileMaker Server). This is critical to prevent attackers from intercepting sensitive data during transmission.
The best way to ensure encryption in transit is to use SSL certificates. FileMaker Server supports custom SSL certificates, which validate the identity of the server and encrypt the connection between the client and the server.
Common Misconceptions: Some developers believe that SSL certificates are only necessary for external-facing servers, but this is not the case. Most security breaches occur from within the network, not from external attackers. Therefore, SSL certificates should be used even for internal servers to protect against internal threats such as compromised user accounts or malicious actors inside the organization.
Plugins and File Access Protection
While plugins are a powerful way to extend the functionality of FileMaker, they can also introduce significant security risks if not managed correctly. Developers must take care to disable unused plugins and control which plugins can interact with their FileMaker solution.
Managing Plugin Security
FileMaker allows plugins to access sensitive system resources, such as SQL databases, network connections, or file systems. If a plugin is compromised or malicious, it could allow an attacker to bypass FileMaker’s built-in security controls. To mitigate this risk:
- Disable plugins that aren’t needed: If your solution does not require plugins, disable the ability to install them.
- Use the FM Plugin Access extended privilege: This extended privilege prevents external plugins from running scripts in your FileMaker file. By disabling this feature, you reduce the risk of an external plugin introducing vulnerabilities into your system.
File Access Protection
File access protection is a feature in FileMaker that prevents unauthorized users from gaining access to the file’s schema or data. In older versions of FileMaker, file access protection was disabled by default, leaving files vulnerable to exploitation. In newer versions, file access protection is enabled by default.
Why File Access Protection Matters: Without file access protection, even well-designed security models can be bypassed in minutes. Attackers can use various tools to access the underlying structure of the file, modify scripts, or gain access to sensitive data. Enabling file access protection closes this vulnerability and ensures that unauthorized users cannot access or modify your solution.
Recommendations:
- Always ensure that file access protection is enabled, especially when working with older files that may not have this feature turned on by default.
- Periodically audit your solutions to verify that file access protection is active, particularly before moving a file into a production environment.
Monitoring and Auditing: The Power of Logs
Logs are an invaluable resource when it comes to monitoring, auditing, and securing a FileMaker solution. Both access logs and event logs in FileMaker Server provide detailed information about who is accessing the system, what actions they are taking, and whether there have been any failed login attempts or suspicious activity.
Leveraging Access Logs
Access logs track every login attempt, detailing the username, IP address, and whether the login was successful or not. These logs are essential for detecting unauthorized access attempts or identifying dormant accounts that have not been used in a while.
Regularly reviewing access logs allows developers to:
- Identify failed login attempts: Multiple failed login attempts could indicate that someone is trying to brute force their way into the system. If these attempts are frequent, it’s a sign that additional security measures, such as account lockout or MFA, may be needed.
- Detect dormant accounts: Reviewing access logs can help identify accounts that have not been used in a long time. These accounts should be disabled or reviewed to ensure they are still necessary.
- Track suspicious activity: Unusual access patterns, such as users logging in from unexpected locations or accessing parts of the system they don’t normally use, could indicate a potential breach.
Event Logs and Monitoring Systems
FileMaker’s event logs provide detailed information about system-level actions, such as failed script executions, server errors, or failed API calls. These logs are crucial for identifying vulnerabilities or configuration issues that could compromise security.
Integrating monitoring tools like Zabbix, New Relic, or DataDog with FileMaker Server allows you to automatically analyze logs in real-time, detect anomalies, and set up alerts for suspicious behavior. These tools can notify you via email, Slack, or other channels if they detect any potential issues, enabling you to respond quickly to security threats.
Archiving Logs: By default, FileMaker Server only keeps two versions of the access and event logs. To retain a complete history of user activity, it’s important to periodically archive these logs. You can set up a regular process to export and store logs on an external system, allowing you to track user behavior over time and investigate incidents that occurred months earlier.
Offboarding Users and Managing Access Lifecycle
One of the most overlooked aspects of security is offboarding—removing access when users no longer need it. Whether an employee leaves the company, changes roles, or takes extended leave, their access to the system should be revoked immediately. However, this step is often missed, leaving systems vulnerable to unauthorized access from former employees.
Best Practices for Offboarding:
- Regularly audit user access: Periodically review the list of active users and verify that each user still requires access to the system. Use the access logs to identify dormant accounts that haven’t been used in a long time.
- Automate offboarding: Integrating with an external identity provider makes offboarding easier by centralizing user management. For example, if a user’s account is disabled in the corporate Active Directory, it can automatically disable their access to FileMaker as well.
Conclusion: Prioritizing Security in Your FileMaker Development Process
Security should never be an afterthought. From the moment you begin designing your solution, security considerations must be baked into the development process. By prioritizing security, you protect not only your clients’ sensitive data but also your own reputation as a developer. Here’s a summary of the key takeaways:
- Secure by Design: Ensure that your solutions are built with security in mind, using FileMaker’s robust security features such as privilege sets, encryption, and external authentication.
- Secure by Default: Avoid risky shortcuts like auto-login with full access. Enforce minimum version requirements, use encryption at rest and in transit, and disable unused plugins.
- Monitor and Audit: Regularly review access and event logs, set up monitoring tools, and audit user activity to detect potential security threats.
- Manage Access Lifecycle: Regularly audit user accounts, disable dormant accounts, and offboard users when they no longer need access to the system.
As a FileMaker developer, it is your responsibility to ensure that your solutions are secure, resilient, and compliant with modern security standards. By following the best practices outlined in this guide, you can build systems that not only meet your clients’ needs but also stand strong against the growing number of threats in today’s digital world.
