Security checklist
Last updated
Was this helpful?
Last updated
Was this helpful?
The primary aim of this checklist is to assist you in building apps that exemplify best-practice security measures. Covering a spectrum of considerations, the checklist addresses areas from environment configuration, roles, and permissions, to scripts embedded within coded components. Depending on the diverse building blocks you've employed, some checkpoints might be optional, offering flexibility within the framework while maintaining security standards.
Most Appfarm Create users have at least one of the : Owner, Maintainer, or Developer, which defines their basic access rights. In the Development environment, the built-in roles describe access to apps, services, and object classes, as well as modification of user accounts, updating app secrets, etc. The built-in roles, however, do not have access to Test, Staging, or Production. To access a client app in these environments, you must have a custom role with the necessary permissions.
All users with access to your apps should be members of at least one . Roles should have descriptive names and clear descriptions.
Learn more about how to .
When setting , operate with the principle of least privilege in mind: all users are given the minimum levels of access – or permissions – needed to perform their job functions. Collaborate on a permissions model together with your stakeholders to leave out any doubts about access control.
On creation, all users should be assigned a suitable role granting correct permissions.
A snapshot procedure should be in place to minimize the risk of functionality loss in case of unwanted changes or irreparable errors.
Make sure only to enable what you need.
are a storage mechanism for sensitive values. All secrets within your app should have descriptive names and a clear description of the secret's purpose. Where possible, secrets should be environment-specific to minimize the damage in case of a potential attack. If, for some reason, users have permission to delete but not to create or edit secrets, consider locking the secret to reduce the risk of unwanted changes.
All should have descriptive names and a clear description of the secret's purpose. Select a relevant role for the service account. Where possible, each service account should have a separate role granting only the necessary permissions.
All action nodes create users with correct roles and permissions.
configuration is set up according to company guidelines.
Review regularly as a pre-emptive measure to check if any irregularities occur, as well as in case of any problems being reported, in order to debug. Logs should be disabled in Staging and Production unless they are being used for an ongoing debugging process.
Backups are important. A is a copy of your solution model at a certain point in time.
All have descriptive names and clear descriptions.
All have descriptive names and clear descriptions.