Any Script can get called anytime by anyone

In the last days we had a discussion with a client about FileMaker 2024 and the quick open feature. The user may press Command-K (macOS) or Control-K (Windows) and search for things. This includes layouts and scripts and they can go to layouts and run scripts, when you wouldn't expect it.

We love to give everyone a reminder on a little security thing: Any script in FileMaker may get called anywhere by anyone.

When you write a script, you usually make assumptions. The script expects to be in a certain layout on a specific record to do its job. You expect it to be called because a user pressed a specific button or used the custom menu to only call it in a specific situation. But your script can be triggered:

  • with the open quickly feature in FileMaker 2024.
  • using the script menu, maybe after switching back to standard menus.
  • via Apple Script
  • via Data API
  • via fmp:// URL
  • via various plugins
  • via another FileMaker file where someone writes a script to perform a script in your file.
  • via Siri intents
  • via notification response trigger

While you could put in some guard rails using the permissions and denying linking your file to another one, we hardly ever want to restrict calling triggers via fmp URLs or plugin since we use that regularly for integrations like with the WebViewer.

Your script should check for context. For example if you expect to be run in a specific layout, you may check with Get(LayoutName) for the current layout name. But then please also check with Get(FileName) for the file name, since you may have the same layout name in a second file! But what would stop someone from having a second file with same name?

The solution is to pick a specific layout in a database and then have FileMaker go there. If you are on that layout already, nothing will happen. Switching layouts may fail due to a validation in the current record in some table, by missing permissions to enter the layout for the current user or by a layout trigger blocking us. We need to check for errors after each "Go To Layout" and exit in case of an error.

Let's check this sample script. It's for exporting records, but the current user may not have the privilege fmexport allowed. That is a specific extended privilege we created and assigned to a few user groups to allow some specific accounts to do exports, but not the normal users entering data. This check should catch a lot of unintended execution of the script. You may add checks to prevent this to run via Data API or FileMaker Go if you like. This script only runs manually in FileMaker Pro or as a scheduled script on the server.

# Stop user messing around
Allow User Abort [ Off ]
Set Error Capture [ On ]
# Check if current user has privilege
If [ Position ( Get ( CurrentExtendedPrivileges ) ; "fmexport" ; 1 ; 1 ) > 0 ]
	# user got privileges for running export script
	Show Custom Dialog [ "No records?" ; "Please find some records first." ]
	Exit Script [ Text Result: "not allowed" ]
End If
# Check for some platforms. Deny for FileMaker Go or WebDirect
If [ Get(SystemPlatform) = 3 ]
	Exit Script [ Text Result: "Script not allowed to be run in FileMaker Go" ]
End If
If [ Get(SystemPlatform) = 4 ]
	Exit Script [ Text Result: "Script not allowed to be run in Web Direct" ]
End If
If [ Position ( Get(ApplicationVersion) ; "Data API" ; 1 ; 1 ) > 1 ]
	Exit Script [ Text Result: "Script not allowed to be run in Data API" ]
End If
# Move to right layout if needed
Go to Layout [ “Orders” (MySolution) ; Animation: None ]
Set Variable [ $LastError ; Value: Get(LastError) ]
If [ $LastError ≠ 0 ]
	# Failed to go to the layout
	Exit Script [ Text Result:    ]
End If
# check whether we have records
If [ Get(FoundCount) = 0 ]
	Show Custom Dialog [ "No records?" ; "Please find some records first." ]
	Exit Script [ Text Result:    ]
End If

Once we passed the checks for extended privileges, for the current platform, moved to the layout and even checked if we got records for the export. Now the data export script can do its job and export the data.

What do you think? Should every script get such a 40 line prelude?

Maybe at least some more dangerous scripts that delete data or export data.


Just today - my first client install of FMP21 - I moved all the users to a custom menu that has CMD-K eliminated. This client is 400 layouts, a thousand or so scripts, so mucking with every script is not viable.

IMHO, Claris needs to make this a selectable option by privilege set.


I've been checking for context for a long time. Only the simplest, context independent scripts don't start with a guard clause. I use a custom function called CorrectContext to test the layout table name.

If [ not CorrectContext( fieldReference ) ] 
    exit script [ blah ]
end if
... script ...

Even so, that is just a sanity check the ensure that I'm in the right spot. It's not security.

The new "Open Quickly..." goes much further than it did when it was in ETS. At that time it was layout mode only and only found layouts. It was effectively a fast layout switcher. And I believe it only referenced the current file ( I may be wrong about this because I didn't use it heavily while it was in ETS).

Now it is public. It references layouts and scripts, and it aggregates them across all open files. It's a Black Hat hacker's dream tool. This is not a case of "you didn't do security right." Open Quickly exposes scripts and layouts that were not able to be seen previously.

if there is any way for them to access standard menus then the game is over. For instance, If your users are able to connect to your system with a file they create, so that they don't have custom menus, then they will see straight past that "fix."


From Wim Decourte - Soliant Consulting

and let's not forget that OQ let's the user spawn a new window, even if you've taken away all menus in the priv set.

1 Like

Having a number of checks at the top of Scripts is a good idea...

Because these checks will be performed at the top of many Scripts, I would (when possible) create a separate Script to be called as a "sub-routine" for each check. This "sub-routine" can then be called using a single line. (A well chosen "sub-routine" Script Name can take the place of a comment.)

Whether these "sub-routine" Scripts Halt or Exit is a subject of debate.
Halt Script can get the job done using fewer lines in the calling Script.
Sometime you need to use Exit Script.
A time and a place for each, in my opinion.

Script Name: _Val current user has privilege_P // called with a Parameter (_P)

Script Name: _Val Check for some platforms_P

Script Name: _Val Move/Go to right layout if needed_P // this one is tricky as you introduce Layout indirection unless you are reading and passing along the LayoutID (and converting it back):

Script Name:_Val window FoundCount > 0 or Halt

More here

reply 1/n

The Call Stack shows you (as seen in the image below) if a Script was called from a (Button).
A Get(CallStack) Function useful for if a Script was called from a button AND for debugging errors, by making it easier to return the Call Stack (which currently can only be done with lots of added code).


Reply 2/n

This concerned me when I first read about Open Quickly/Command K, but upon testing it behaves in a logical way. If a user's privilege set has no access to the script workspace and layouts are hidden, then they are inaccessible from within this new menu addition.

Neither is it added to existing custom menu sets, hence; files designed as apps using these are not affected. The primary risk is for very old solutions that allow everyone to access using full access, which do still exist out there especially in-house developed solutions. However, these are already at risk and this just adds another level of access to those that have already been there using the historical navigation menus.

Touching on the 'black box' scripts subject within another post within the Soup, we'd usually add the prelude Christian proposes. However, for scripts that are run from a specific layout, from a specific button we wouldn't.

To summarise, a solution that has appropriate security and custom menus shouldn't have any additional exposure from this new menu.


Many solutions that were adequately secured via FMP UI before the introduction of Open Quickly can now be exposed. There is an new, and a very powerful, discovery tool in FileMaker Client that wasn't there before. It lowers the bar for entry into systems that are not completely secure.

Hi Malcolm

Could you expand on this please? I’d be interested to know what were the adequately secured UI elements were that are now exposed by Open Quickly.

We control virtually all security via the UI, other than Full Access and set the layouts, value lists and scripts to view and execute only, with Records set to Create, edit and delete in all tables. We find the field level security makes data take on from say an SQL system we’re replacing almost impossible. Hence; amost all access is controlled by fields set in our Human Resources module (that the database administrator can grant access and features to users), scripts and custom menus, with all layouts hidden and navigated to using buttons or scripts.

As yet, I’ve not found anything within Open Quickly that gets around these.

Many thanks

I've said it before but it needs to be said. Open Quickly does observe security. If you are using a security settings then Open Quickly doesn't break your security model.

There are many different ways to access a filemaker database. FileMaker didn't have the server/client separation that other database systems had. FileMaker was server and client bundled into a single app. For a long time FileMaker was the only client, and the only interface for a FileMaker database.

Over time, many different interfaces for talking to FileMaker databases arose: AppleScript, XML, CWP, ODBC, JDBC, Data API, oData. Each of these opens up FileMaker in slightly different ways. For instance, you could ask for the names of all the tables, and the names of all the scripts. But it was also possible to close these off using extended privileges and the security settings. You could set up a security setting for CWP that only allowed access to one layout, and two or three scripts.

Now lets imagine a scenario. We have a multi-file solution. One of the files contains a script which has a single step: Truncate table [Current Table].

Prior to the introduction of Open Quickly, the UI of FileMaker client limited user interactions. If we didn't allow any scripts to be seen in the script menu the user didn't see them. If we used custom menu sets then we controlled access to scripts, including providing parameters to them. The underlying scripts, and the layouts that are used, are all available to the logged in user. The security settings for the user allow them access to those objects. However, instead of being accessible via the user interface, they are now visible from anywhere within the entire set of open files. I can run a script from a hidden, but open, file. But what if that script makes presumptions, for instance, it expects to be called from one button on one layout. Using the UI the user can only to that button after they have been through a series of interactive queries. Perhaps that layout is not a part of this user's security set but the script is not restricted from the user. Using Open Quickly that user can run that script. But now it runs in the wrong context.

[ edit: Just wanting to add an example ] This is like having every script in your solution appear in the script menu. There is so much potential for damage that can flow from Open Quickly.


There should be a kill switch to turn it off!
Got a new client with a 50 file solution and hundreds of scripts and layouts and it will take weeks to secure all properly until they can upgrade to FMP21 if they can afford the time to secure it.

1 Like

Hi Malcolm.

Perhaps in someways this could be a good thing. For Open Quickly to be a problem, there must be an exposure within a system. I can't imagine releasing a system that allows data processors access to the script workspace, and any scripts left available within the Scripts menu can run contextless regardless. I do appreciate that navigation via the layout menu could still be around, but if that's the case then the users can select the layouts regardless, whether they use Open Quickly or not.

The Claris Help page for using Open Quickly states that it can:
Open a FileMaker Pro app
Open a layout in any open app
Open a script that you have privileges to modify in any open app
Run a script that you only have privileges to execute in any open app

Open Quickly doesn't cause a problem, as the risk already exists for it to be a problem. Open Quickly does increase the risk though and, hopefully as a result of this, the exposures will be dealt with by the database developer/administrator.

Kind regards

@FileKraft, as per my reply to Malcolm, if a system needs securing ready to upgrade to v21, then it needs securing regardless of an upgrade.

Last year we moved a client's system that consisted of 57 files from a local server to one of our cloud servers. All users had full access to all files. The fact this system consists of 57 files consisting of a single table indicates how long it has been around and used. To my knowledge, there has never been a problem with someone running scripts unnecessarily, but of course the risk has always been there.

It goes without saying that there is no way we'd have put this on the cloud, hence we added security privilege sets to each file and added a 58th file (as there was no obvious file to introduce the necessary tables) that controls the addition and deletion of users and password management.

The above had nothing to do with Open Quickly, simply good system management.

It still needs a kill switch ..

I think Claris works on a checkbox.

See the talk on the end of the FMDisc with Rick Kalman

1 Like

And we’ve all lived with ‘Delete All Records’ in the standard menus forever? :wink:

1 Like

Me gets the feeling that the concept of public and private scripts, like functions (or methods, etc) in object oriented languages, would be greatly beneficial in FileMaker.

1 Like

Thanks @MonkeybreadSoftware.

The meeting runs for several hours, so for those who simply want to see what Rick says about Open Quickly, the discussion starts at 1:54.


Open Quickly is providing the exposure. It is creating the problem.

  • A layout that a user's privilege settings allow access to but was never visible to the user is now able to be accessed directly.

  • A script that a user's privilege settings allow access to, but was only exposed via a button (that was in a specific context and carried script parameters to control it's behaviour) is now available from any context and without script parameters.

You are taking a sanguine view but it is important that everyone is advised that FileMaker now includes a tool that exposes all of the objects that a user has permission to view. It is a significant change and has serious ramifications.


Hi Malcolm

Approaching 40-years working with IT, sanguinity is a prerequisite!

I'll have a look at the video later and I agree about this being a significant change and everyone should use this as a reason to revisit their systems' security.

I'm still not sure where you're coming from on this one? A user can have access to all layouts and add, edit and delete in all tables but would need to have a layout included in the layout menu for them to be able to open it in Open Quickly. If it is in the layout menu, then it can also be accessed from there and from the Layouts > Go to Layout menu. Open quickly simply adds a 3rd way to access this.

I've one layout scenario I've not tested yet, which would be a hidden status bar that has layouts exposed in the layout menu. Working on the basis of security by obscurity is no security at all, I'd still consider this an exposure regardless of Open Quickly, for example via the Layout menu again. Yes, this could be solved by using a custom menu, but if that's the case Open Quickly won't appear anyway.

Again button driven scripts do not need users to have access to the script workspace. If they've access to the workspace, then they've access to all scripts. If they don't, then Open Quickly cannot open any script.

Put simply, a database with security exposures is at risk regardless.

Sorry to go on, but I think its really important that we don't go scaremongering when Open Quickly does respect basic security measures to prevent some of the scenarios being listed here and I still do not believe Open Quickly is providing the exposure or creating the problem. It is simply adding to the exposure and problem that already exists.

Equally, I'm more than happy to be proven wrong as so far my tests reflect what I've written within this thread.

Kind regards