This doc page has moved! You should be automatically redirected to the new location. If you are not redirected automatically, follow this link to the new page.

You are here: Using eBay RESTful APIs > Security and your eBay apps

eBay application security

When developing eBay applications, you (and eBay) need to be security-aware. Applications often request, reference, or otherwise make use of data such as:

  • Credit card or other payment credentials and information.
  • User's personal identifying information, such as names, addresses (email and physical), phone numbers, and so on.
  • Application usage credentials and tokens.
  • Business intelligence data (such as order sizes, sales data, and other information that has the potential to be misused by competitors and other businesses).

How eBay protects data

For obvious reasons, we cannot go into enormous detail about the security systems that eBay maintains to prevent someone from to break in to our systems and compromising user data. But we can outline the industry standard practices with which are in accord.

eBay servers and data warehouses are each put in a specific security zone. The more important the data, the greater the amount of security the server receives.

Registered user credentials are persisted on machines in a high security zone:

  • eBay doesn't provide developer access to those systems.
  • All access is over HTTPS.

Personal identifying information (PII) is persisted on machines in a heavily fortified zone. eBay uses access controls, encryption, and other leading industry practices to secure PII data and machines.

Credit card numbers and other Payment Card Industry (PCI) specific data is classified as restricted. This data:

  • Is persisted in security hardened environments.
  • Undergoes quarterly security audits.
  • Has all its data transmission over HTTPS.
  • Has access protected by predefined authorization policies, and users can access the data only after they have provided authentication.

How application developers should protect data

As an application developer, you are responsible for securing your users' data and accounts. As part of the Compatible Application Check and the Checklist for Going Live, you are expected to follow the OWASP secure coding principles and also address the OWASP Top 10 Most Critical Web Application Security Risks.

The following sections list eBay-specific actions are either expected of you and your applications, or are generally good security practices to follow.

User credentials and security tokens

  • You are expected to use the eBay provided secured and authenticated services to perform user authentication with eBay.
  • Encourage users to reset their passwords if they suspect their login credentials are compromised.
  • Periodically rotate your client secrets (aka cert ids or certificate ids).
  • If there is a client secret breach, ask eBay Support to revoke any active tokens. Active tokens can exist for a considerable post-rotation period.
  • NEVER send client secrets via unencrypted email.
  • Only send client secrets via encrypted email to trusted colleagues and eBay Support.
  • Don't send client secrets to random eBay employees; make sure you send this sensitive data to only eBay support members.

General authentication

  • Require validation on both the client and server sides of your applications.
  • Always encode output.
  • Only use HTTPS for any authentication with SHA-256 certificates.
  • Use role based authentication with multiple session identifiers.

Password authentication

  • Force a complex password policy.
  • Do not use pictures or biometrics as passwords.

Session management and cookie authentication

  • Invalidate cookies on both the client and server sides.
  • For each session cookie, hash all the cookie's keys-pair values to create a unique key that the server associates with a user.
  • Invalidate any session identifiers after a successful logout or timeout on both the server and client sides.
  • After a user authenticates successfully, assign them a new session ID.

Data protection and cryptography

  • Use public key cryptography for initial encryption, exchange a symmetric key, and then use a symmetric cipher (which have less overhead than asymmetric ciphers).
  • Hash ALL transported or stored sensitive data.
  • To avoid cryptographic attacks on data transmission, when sending data:
    • Assume M is the message, Hash(M) is a hash function, and Enc(M,K) is the encrypt function with key K
    • Send Enc(K, [ Hash(M), M ] ) to satisfy confidentiality and integrity.

Communication and HTTP security

  • Always send PCI data via HTTPS.
  • Perform all sensitive data read/writes over HTTPS
  • Do not use a weak SSL implementation, and always use HTTPS.
  • Remove all sensitive data from GET requests.
  • Avoid using GET requests with/for secured data elements. GET can load sensitive data into the URL.

Security configuration

  • Ensure servers do not disclose information about themselves or the technology used.
  • Properly configure SSL.
  • Secure cookies to have the HTTP-only flag set.
  • Set the .htaccess file to prevent directory listings and remove file extensions from displayed URLs.