.fusion-header-wrapper { padding-top: 0px;background: #000dbb !important;} #page-header { display:none;} .fusion-header-wrapper.fusion-is-sticky { visibility: visible;}.post-content {padding-top: 30px;}
/* CSS to help with ACF styling */ .fusion-logo img { opacity: 0; } .fusion-main-menu > ul > li > a { border-color: #444; } .fusion-logo-link { background: url(https://www.fairwarning.com/wp-content/themes/Avada-Child-Theme/images/dark-logos2.png); } .fusion-main-menu .fusion-main-menu-icon:after, .fusion-main-menu .fusion-widget-cart-counter > a:before { color: #696969; } .fusion-header { background-color: #fff !important; } .fusion-header-wrapper { padding-top: 0px; background: #ffffff !important; } .fusion-is-sticky .fusion-main-menu > ul > li > a { font-size: 14px; } .fusion-main-menu > ul > li > a, .fusion-main-menu > ul > li > a .fusion-menu-description { color: #444 !important; } .fusion-main-menu > ul > li > a:hover { color: #444 !important; font-weight: bold; } .fusion-body .fusion-main-menu .current-menu-parent > a { color: #444 !important; font-weight: bold !important; } .fusion-header-wrapper { background: transparent !important; }
/* CSS to help with ACF styling */ #page-header .h1 {color: #444;} #page-header h2.text-color-xsdn-color {color: #444;}
/* CSS to help with ACF styling */ #page-header .h1 {color: #fff;} #page-header h2.text-color-xsdn-color {color: #fff;}
/* CSS to help with ACF styling */ #page-header .h1 {color: ;} #page-header h2.text-color-xsdn-color {color: ;}
/* CSS to help with ACF styling */ #page-header {background-color: #031ac3;}
/* CSS to help with ACF styling */ #page-header {background: #fff url() center center; padding-top: 0px; padding-bottom: 0px; } @media all and (max-width: 4699px) and (min-width: 1925px) { .title-and-subtitle-background-image { padding-top: 3% !important; padding-bottom: 3% !important; } }
/* CSS to help with ACF styling */ #page-header {background: ;}

APIs are incredibly useful -- and they can also introduce risk to an organization

APIs are everywhere. They allow applications to communicate with one another, trading essential information that enriches user or customer experience and helps you extend your investment in mission-critical applications like Salesforce. According to a recent study by Imperva, the typical organization manages an average of 363 APIs, and more than two-thirds of organizations expose their applications’ APIs to the public to allow partners and developers to leverage their software platforms and apps. That makes API security paramount for overall data security.

Yet APIs also introduce a new vulnerability to many organizations. The endpoint could be an issue, but security problems will more likely arise when data is being transmitted between applications via an API call. The average web application or API has 26.7 serious vulnerabilities, yet an Akana survey showed that over 65 percent of security practitioners don’t have a way to ensure secure API access.

Recent headlines of breaches across industries continue to shed light on the issue:

  • Panera, where an unauthenticated API endpoint led to an eight-month leak of the data of more than 37 million customers.
  • Venmo, which was found to have exposed the details of hundreds of millions of transactions via a poorly secured API.
  • Equifax, in which 143 million people had sensitive personal information exposed due to a vulnerability in the framework used to create its APIs.

And HIMSS, in its June 2018 Healthcare and Cross-Sector Cybersecurity Report, highlighted API vulnerabilities as an emerging threat in the healthcare space.

Is That API Secure? 6 Things to Watch For with API Security

So how can you leverage the power of APIs without opening your data to external attackers and data breaches and leaks? First, it’s important to understand some common API vulnerabilities – and how to determine whether they could be a problem in any third-party APIs you need to enable.

Six of the most common API security vulnerabilities are:

  1. Code injections. An injection occurs when an attacker “injects” a malicious piece of code into the API code. This can allow the attacker to extract information from your organization, or your partner’s organization. Ask: Did the API developer include threat protection measures to guard against injection attacks?
  2. Poorly authenticated API: A poorly authenticated API, like that in the Panera breach, can leave sensitive data open to attackers. In fact, in an analysis of more than 413 million daily API login requests, Akamai found that a whopping 30 percent of the logins were fraudulent. Ask: Did the API developer use industry-standard authentication and authorization measures like OAuth/OpenID Connect rather than only TLS?
  3. Denial of Service (DoS) attacks. These occur when attackers flood APIs with calls, causing the application to slow or shut down altogether. Ask: Did the API developer follow best practices like rate-limiting, blocking malicious IPs and/or enacting anti-scraping policies?
  4. Unsecured cardholder data or PHI: Data could be accessible in tools intended for debugging. Ask: Did the API developer protect traffic with best practices like encryption and tokenization for cardholder information?
  5. Replay attacks: In replay attacks, or “transaction replays,” the attacker replays a legitimate user request to compromise authorized credentials. Ask: Has the API developer enacted rate-limit policies to throttle requests — or do they monitor for potentially malicious traffic patterns?
  6. Sensitive data left in URI keys: Some APIs may send the access key as part of a Uniform Resource Identifier (URI), but URI details can appear in browser or system logs, revealing keys, passwords, and other sensitive data. Ask: Does the API developer transmit the key using URI, or the preferred HTTP POST method?

In Your Court: Further Measures for Securing API Access

In addition to ensuring any partners have done their due diligence with their APIs, there are a number of ways your organization can help prevent API security issues from laying bare your most sensitive data.

Create a dedicated integration user

First and foremost, remember that, in Salesforce and other mission-critical cloud applications, an API is just as much of a user as an employee or third-party contractor. When enabling an application’s API access to Salesforce, consider creating a Salesforce user that’s only used for that unique integration. Set the user’s permissions to “API only” to specify that the user can only log in via the API. And make sure to avoid granting the permission “modify all data” to ensure the API cannot view all data stored in the database or edit any editable fields.

Set controls for the access and activity of an API user

According to Salesforce, organizations might also consider restricting the following for a more secure integration:

  • User access: Grant the integration user access to only those objects required to the integration, to minimize the amount of data that would become vulnerable in the event of a breach.
  • IP address: Lock the integration user down by IP address or range to minimize the risk of injection and other attacks. This can be done on the Salesforce side (i.e., by restricting IP access to only the partners’ servers) and on the partner side (i.e., by allowing requests only from Salesforce’s IP ranges).
  • Passwords: Ensure all passwords are strong (e.g., contain at least 20 random characters).

Salesforce offers additional API integration security best practices here.

Monitor API access

At the SANS Secure DevOps Summit, Elastic Beam CEO Dore Rosenblum shared an overview of the API security landscape – and posited that foundational API security measures like OAuth and throttling, while necessary, are no longer enough to constitute a strong API security posture. Monitoring API access and activity, then, can reveal vulnerabilities to an organization that may have otherwise gone undetected.

“A lot of apps — Salesforce itself, even – require access to an API to make a connection,” said Thomson Reuters’ Head of CRM and Business Information Andy Louca on a recent webinar. “Unless you have API enabled, some of those even basic connected apps won’t work. You can, however, control and monitor those connected apps with reporting and event logs.”

When selecting a solution to monitor API access to Salesforce and similar cloud applications, make sure your vendor follows the best practices listed above if they use an API themselves. Also consider choosing a partner that allows for user behavior analytics to detect anomalous patterns in API activity, calls from specific IP ranges or geographic locations, and more.

Treat APIs like any other user in your cloud environment, and practice the principle of least privilege to ensure it can’t access more than is necessary. By improving your API security, you’ll take strides toward improving your overall posture – and protecting sensitive data from falling into the wrong hands.

Start your 14-day free trial to begin monitoring for API access to Salesforce — and more
Related Blog Posts
View All Blogs