Skip to main content

Security Questionnaire

What is the approach to API Authorisation to validate access is segregated to minimum scope and limited to least privileged access?​

We use JWT tokens issued from an identify provider (IdP), the tokens have Scopes defined which permit access to different API operations for their integration purposes.

Individual integration partners allowed scopes can be provided upon request.

What are the mechanisms in place to ensure Authentication of API use remains appropriate? Is API access reviewed on a regular basis?​

  • We have token expiration policy of 24 hours.
  • Access data within Tenants is defined by our customers not by MWI.
  • At anytime a customer can request third-party access is removed.

Is Multi-Factor Authentication used? If so, how is this implemented (e.g. IP restrictions, certificate)?​

  • The production API Gateway has IP restrictions linked to the Client Key.
  • Development / Sandbox instances do not have IP restrictions, but can be implemented upon request, this is to allow ease of use when developing the application.

What checks are done against top threats?​

  • We follow Security by Design and have implemented multi-layered security checks on every API request.
  • The API Gateway and backend Services are scanned using Static Analysis software and regular penetration tests.
  • Backend services are only accessible from the API Gateway which is the only public facing component of the API infrastructure.

What monitoring of API use is done (primarily to reduce excessive data exposure)?​

  • The API Gateway has many built in metrics, monitoring and alert capabilities, we also use external tools for the entire infrastrucutre.
  • We also track every request made and key information surrounding it such as origin IP, endpoint requested, tenant requested, HTTP status code.
  • Infrastrucutre access is restricted to MWI Animal Health staff in the UK which utilises Azure including constant Azure security tracking, monitoring with MFA access by staff enforced.

What development standards are in place to guide development of the API’s?​

We have a set of Standards for Restful services

  • Request payloads are limited in records returned with paging.
  • Remove unnecessary headers from reponses.
  • Validations of provided parameters.
  • Injection protection through with ORM libraries.
  • Running security static analysis of the code.
  • Regular reviews of new public vulnerabilities with frameworks and libraries.

Has an analysis against the OWASP API Top 10 Security issues been performed?​

Yes we have reviewed and analysed against these threats:

  • We are verifying Authentication and Authorisation on every API call
  • Identifiers are UUIDs, patterns cannot be used to brute-force attack.
  • We have a policy on the calls using standard JWT with encryption generated with the Identity Provider, all the JWTs are created with the Audience set to our API Gateway, with all backend services checking JWT as standard.
  • Tokens are generated with expiration policy.
  • Scopes are defined to each grouping of data, and third-parties can see or manipulate only the data they are permitted.
  • Endpoints (resources) are granular enough to not expose all the data in large single requests, e.g. contact numbers is separate from addresses.
  • Rate limiting by IP and rate limiting by Client Key.
  • Paging of API payload responses.
  • We do not allow CORS.
  • Injection is avoided with parameter validations and we use standard ORM libraries.

Are all elements of the API use up to date and supported systems/software?​

  • We use many Azure cloud native components which is automatically kept up to date and is always in a supported state.
  • We use several tools for reviewing frameworks and libraries for vulnerabilities.

The API launched in September 2021 and as of March 2025 no security incidents have occured.

What encryption methods are used?​

  • Only TLS 1.2 encryption is allowed.

Ciphers:

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384

Have default settings on API systems/software been changed?​

Yes – We have configured specific policies as previously defined.

Have any unused or redundant APIs been removed?​

Currently no redundant API's exist due to being in the initial development stage, however we will be reviewing all API's in a holistic approach with redundant flags and sunset dates when required.