Data and security

PrimaryBid uses best-in-class observability and security tools and measures to maintain the highest level of protection against API misuse and cyberattacks. Our security practices ensure that:

• All API requests we receive are from legitimate sources.
• All API responses are valid and protected against exploitation.

To accomplish this, we apply defence-in-depth, including:

• Robust information security programme: our security programme adheres to the highest standards and practices, leveraging the NIST CSF.
• Secure software development: we develop our systems and software with security in mind throughout the software development lifecycle with continuous vulnerability assessment. We utilise the best-in-class tools and processes from planning to deployment and operation.
• Security observability: the process of monitoring and logging the usage of the API, with behavioural insights, and advanced threat-hunting capabilities.
• Cloud security & compliance: security is a shared responsibility in the cloud. We ensure all resources and cloud service configurations follow the best security practices while being compliant with regulations and our security frameworks. We use highly effective autonomous systems to monitor and respond to threats on our cloud accounts and workloads.
• Network security: API environments and application tiers are segregated at the network layer, with network access controls and dynamic firewalls. Identity being the new perimeter, we centralised Identity and Access management.
• Application security: security controls applied on multiple layers of the application ensure the authorised and legitimate use of our APIs. We address all OWASP Top10 API security risks.
• Data security: facilitates data integrity and granular access control. Users cannot access API data they’re not allowed to see.

Secure by design

We abide by the Secure, Private & Compliant-by-Design paradigm, with specific strategies, tactics and patterns implemented at every level:

• We encrypt all data in transit and at rest.
• We also require partners to encrypt data at rest.
• We employ principles of least privilege and role-based access.
• The network connectivity to endpoints is strictly and narrowly shaped.
• External companies regularly pentest our API to signal system weaknesses.
• All network, data, and user activity is audit-logged across all systems, including API/integration endpoints.

Our engineering designs are difficult to compromise because of characteristics such as the isolation of system functions, an absence of exposure points, and validation of communications.

Encryption in transit

We use a widely adopted encryption-in-transit protocol called Transport Layer Security (TLS). This layer of cryptographic security encrypts data, blocking hackers from accessing the sensitive information transmitted over the Internet, through the API.

With TLS, the API accomplishes three goals:

• Integrity: verifies if data has not been altered by unauthorised parties.
• Authenticity: confirms the identity of the trusted parties exchanging information.
• Privacy: creates a secure client/server channel and hides the data from third parties.

Encryption at rest

We utilise strong industry-standard encryption algorithms and secrets management to protect data in our data stores in all environments.

IP allowlisting, authentication, and authorization

All endpoints require authentication (API keys or OAuth). To further mitigate security risks, apart from using two different API keys to authenticate users, we added an extra layer of security - IP allowlisting. IP allowlisting gives us a higher control over who has access to our resources.

In short, Partners have to send us a list of IP addresses they use to access our servers. By authorising them as trusted hosts, we make sure the API only accepts requests sent from those IPs; this limits our attack surface and makes our API more resilient to cyber-attacks.

After we successfully authenticate a user who makes a request to the server, we make sure that we grant them access only to the methods and resources they are authorised to use. Moreover, according to the REST API guidelines, we authenticate and authorise each API call, even if it’s made by the same user.

Access management

We design processes and API access by following REST API principles such as:

• The principle of least privilege: we give users the minimum set of permissions required to perform certain tasks at a given time, and nothing more.
• Zero trust: we don’t implicitly trust users or devices by default. We restrict access to data until they are fully authenticated and authorised.
• Role-based access control (RBAC): we grant access to resources based on predefined user roles and privileges within the organisation.

Penetration testing

Instead of just following a traditional "one-off" approach (undertaking security testing just before we go live), we continuously test and assess the security of our API infrastructure during design, build, and beyond the delivery phase.

Apart from having in-house teams to test our API security, we employ third-party penetration testing for our cybersecurity risk assessment. Also called pen testing, API penetration testing simulates a real-world cyber-attack. The purpose is to assess the security of the API design to prevent data breaches and unauthorised access.

Tests attempt to exploit issues, report the results, and strengthen the API defence. They can uncover potential vulnerabilities such as the disclosure of confidential information, input validation flaws, code tampering, insufficient cryptography, broken authentication, or improper platform usage.