Site Security Best Practices:

At Axero, we have a continuous commitment to protect the security and privacy of our client’s sensitive data. Please review some of the most important security settings to ensure you are following best practices and communicating those best practices to your users.

Site settings

Documentation: Site Settings 

Settings to review:

1. Allow access only to registered members - If checked, people must register and login to the platform before accessing anything. If unchecked, then your platform can be viewed by Guests in a read-only mode.

Best practice: Checked ☑

2. Auto-approve members - If checked, then people will be automatically approved as members once they confirm their registered email. If unchecked, then the system admin will have to manually approve every user even after they confirm their email. 

Best practice: Unchecked ☐

3. Allowed email domains - You can restrict user registrations to specific email domains. This is useful if you only want people to register using your company email domain. Enter a list of comma separated values (e.g. yourdomain.com, yourotherdomain.com), or enter * to allow any domain.

Best practice: Restrict user registration to your company email domain only. 

Email settings

Documentation: Email Settings 

Settings to review:

1. Enable email sending - Based on actions that people make in the platform, notification emails are sent to other people associated with the activity. If you do not want these emails to be sent, you can turn this off. Leave this feature on if you do want these emails to be sent.

Best practice: Client preference

REST API settings

Documentation: REST API Settings 

Settings to review:

1. Enable REST API - You can use our REST API to access your data and perform functions in Axero.

Best practice: If you are not leveraging REST APIs, this setting should be unchecked ☐

2. Select users who can access the REST API - The REST API key is tied to the user, roles and permissions in Axero Users will be granted or denied access to content or functions in the REST API based on the users’ permissions. It's standard to create a master system user with Site Administrator role to perform administrative functions against the REST API.

Best practice: Only the Site Administrator role should be checked ☑

User section permissions

Documentation: User Section Permissions 

Settings to review:

1. All permissions - You should review all permissions for roles other than the site administrator. 

Best practice: Users or members should only have “View User Profile” and “Edit” access if required. 

Login

Documentation: Login , Edit Edit Profile Page , Edit Registration Page 

Settings to review:

1. Edit login page - The login page is the front door to your site. It should be configured with the login paths you are actively using (e.g., SSO, email/username/password, two-factor authentication, and/or social logins).

Best practice: Set the permission for inactive login widgets to Site Administrator only so they will not appear for users logging in.

2. SSO auto-login - If your site uses Single Sign-On (SSO) and has auto-login enabled, users will not see the login page when they visit your site. Users will only see the login page of your SSO provider. You can check if auto-login is enabled by navigating to System Properties and searching for EnableAutoLoginViaSAML. 

Best practice: Enabled for clients who only leverage SSO logins.

3. Edit registration page - You can hide the registration form to prevent people from registering on your site.

Best practice: Hide the registration form if you are provisioning users or relying on an integration to do so. 

4. Set Maximum Invalid Login Attempts - You can set the maximum number of invalid login attempts before an account is locked. Go to Control Panel > System > System Properties and search for MaxInvalidLoginAttempts.

Best practice: Set a maximum of 5 invalid login attempts.