Comment on page
Security checklist
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 built-in roles: 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.
- Correct built-in roles are granted to all team members according to the development team’s needs.
All users with access to your apps should be members of at least one custom role. Roles should have descriptive names and clear descriptions.
- All custom roles have descriptive names and meaningful descriptions.
- Correct custom roles are granted to all app users.
When setting permissions, 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.
- All custom roles have access to the needed apps.
- Access to services is granted to the correct service account.
- All custom roles have the correct create, read, update, delete, and aggregate permission to all object classes.
- All custom roles have access to the correct environments.
- All custom roles have correct permissions to accounts and roles.
Secrets 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 secrets have descriptive names and clear descriptions.
- All secrets have a set environment (recommended).
- All secrets are locked (recommended).
All service accounts 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 service accounts have descriptive names and clear descriptions.
- All service accounts have correct roles, granting necessary permissions.
On creation, all users should be assigned a suitable role granting correct permissions.
- Only authentication providers that are in use are enabled.
Review logs 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.
- Logs are enabled for development and test environments.
- Logs are turned off for staging and production environments.
A snapshot procedure should be in place to minimize the risk of functionality loss in case of unwanted changes or irreparable errors.
- A snapshots procedure is in place, and snapshots are taken regularly.
- Snapshots are taken before major changes.
- Auto-snapshots are enabled.
- Logging is enabled (can be turned off once the development is completed).
- A readable ID is set.
- The correct service account has access to each service.
- For requests and response, only input and output needed for the service to function is allowed.
- All API keys have an expiry date and a routine for renewal.
- The scope for all APIs is set correctly and only has the necessary permissions.
Make sure only to enable what you need.
- GraphQL is only enabled in test environments. Only enable in Production when in active use.
- API Services: API explorer is only enabled in test environments. Only enable in Production when in active use.
- Scheduler: only enabled when in active use
- Log options: logs are enabled.
- App security: unauthenticated access is by default turned off and should not be enabled unless unauthenticated access to an app is required.
- User account manipulation: by default, the user account manipulation is turned off. It should only be enabled when necessary and in active use.
- Test cases are defined, allowing thorough testing of an app under development and before deployment.
- Filters are reviewed regularly to ensure that end users don't have access to data that should be restricted.
Last modified 3mo ago