Credential Storage in FileMaker Solutions
BeginnerHow to store API keys, passwords, and secrets within a FileMaker solution safely -- and what never to do.
What you'll learn
- Why global fields and layouts are unsafe for credentials
- Encrypted field storage for credentials
- Fetching secrets from an external vault at runtime
- The no-credential-in-DB approach using environment variables via PSOS
FileMaker solutions often need to store credentials for external services -- email SMTP passwords, Data API service account passwords, API keys, and encryption keys. Storing these incorrectly is one of the most common security failures in real-world solutions. A cleartext password in a global field is a credential waiting to be stolen.
What NOT to do
Never store credentials in: global fields (accessible to any user, logged in any export), cleartext text fields (appear in reports, exports, FileMaker logs), layout objects (label text, default field values), or script comments. These are all readable by anyone with access to the file or its exports.
// WRONG: credential in a global field Set Field [ Globals::SMTPPassword ; "mypassword123" ] // WRONG: hardcoded in script SMTP Send Mail [ Server: "smtp.example.com" ; Password: "mypassword123" ]
Sign in to track your progress and pick up where you left off.
Sign in to FM Dojo