MYOB Developer Security Requirements

Please note: The MYOB Developer Security Requirements will come into effect as of Tuesday 17th January 2023

MYOB takes the security of data seriously. To ensure the safety of the data that is accessible through MYOB’s APIs, the following baseline security requirements are expected to be in place for all consumers of MYOB’s data environment, including Developer Program Partners.

These requirements are aligned to the DSPANZ Security Standard for Add-on Marketplaces and are required to be met under the Developer Program and Platform Terms and Conditions. If you are unable to comply to these requirements, you are required to notify MYOB in writing of your action plan identifying the actions that will be taken to remediate the any gaps.

1. Encryption Key Management

Verify that your app meets these requirements for OAuth token management.

  • Oauth tokens or customer-identifying information must not be exposed within your app or shared with other parties. Oauth 2.0 must be used.
  • Token management once a user completes the Oauth authorization workflow
    • Encrypt and store the refresh token in persistent memory.
    • Encrypt the refresh token with a symmetric algorithm (3DES or AES). AES-128 or greater is preferred.
    • Store your AES key in your app, in a separate configuration file.

2. Encryption in Transit

TLS version 1.2 using AES 256 or higher with SHA-256 is mandatory and must be used.

Web application endpoints that receive sensitive customer information (including “personal information” as the term is defined within the Privacy Act 1988) and/or authentication tokens in URL parameters must not return HTML content via an HTTP Response Body. This is to prevent sensitive customer information from being accidentally leaked to third parties in the subsequent HTTP Referrer request headers. Instead, the web application endpoints should implement a 302 Found redirect. This is particularly important when application end points are handling authentication tokens.

3. Authentication

Ensure that strong customer authentication is enabled (Multifactor Authentication is mandatory) or single sign on with MYOB credentials (Multifactor Authentication mandatory).

4. Indirect access to data

All third-party access to customer data must be clearly stated within your applicable terms and conditions and have a justifiable business need. Any such access is subject to any limitations or prohibitions on third party access as described in the Developer Program and Platform Terms and Conditions.

  • Third party access may include access via an external API, or through data that is stored.
  • Justifiable business needs may include (but are not limited to) the utilisation of third-party services, which is functionally required. For example, the use of third-party biometric services.

5. App server configuration

Ensure your server’s configuration follows industry accepted hardening practice for example:

6. Vulnerability management

Follow an industry accepted standard for secure code development such as OWASP Top 10 to protect against vulnerabilities such as:

  • Cross Site Request Forgery
  • Cross Site Scripting (including reflected and stored cross site scripting)
  • SQL Injection
  • XML Injection
  • Authentication, Sessions Management and Functional level access control (if any)
  • Forwards or redirects in use have been validated
  • All app session cookies have the following attributes set: Secure and HTTPOnly

7. Encryption at rest

  • Encryption at rest using NIST Cryptographic Mechanisms is mandatory for data repositories that hold or manage sensitive commercial or personal information.
    • Examples may include;
    • Full-disk, container, application or database level encryption techniques.
  • We define sensitive commercial or personal information as information which if disclosed could cause harm to the individual or organisation.
    • Examples include:
    • Personal - date of birth, tax file number, address, income, biometric, credit history etc.
    • Commercial - financial, transactions, accounts, trade secrets etc

8. Audit logging

Audit logging should include both application level (access logs) and event-based actions. You should consider your environment and what logging should be implemented and ensure that the logging records include the following where applicable:

  • Date and time of the event
  • Relevant user or process
  • Event description
  • Success or failure of the event
  • Event source e.g. application name
  • Physical asset location and identification

Audit logs must be retained for as long as appropriate to enable future investigation. In most cases logs should be kept for a minimum of one year. Logs must be immutable and secure.

9. Data hosting

  • Ensure client data is not hosted in high-risk areas. Australia and New Zealand are considered low-risk areas.
  • Please contact MYOB in the event of data being stored anywhere other than Australia and New Zealand. MYOB may need to contact government bodies for advice and exemptions.
  • Consideration needs to be given to country, legal, contractual, access, sovereignty, and counter-party risks.
  • 10. Security monitoring practices and breach reporting

  • You need to be able to demonstrate that you scan your environment for threats and that you take appropriate action where you detect anomalies. Monitoring can be at the: network / infrastructure, application, or transaction (data) layer.
  • Where anomalies are detected, you must report these to MYOB, providing enough information to enable further monitoring and/or preventative action.