{{announcement.body}}
{{announcement.title}}

Shadow APIs: Four Reasons to Come out of the Shadows

DZone 's Guide to

Shadow APIs: Four Reasons to Come out of the Shadows

While you may think you're doing some good by operating in the shadows, here are some reasons to reconsider.

· Security Zone ·
Free Resource

Shadow APIs: Four Reasons to Come Out of the Shadows

Shadow APIs are those that are published outside of a defined process that may include security and peer review. Just as was the case with shadow IT, where apps were deployed, or public cloud instances established outside of a defined process, the shadow API owners are doing what they believe is right for the business. The API owners may not be aware of a publication process, they may believe they have autonomy to publish or, they may not fully understand the risk associated with publicly exposed shadow APIs.

Regardless of the reason, shadow APIs are rapidly becoming a problem for organizations as a whole. The reason? APIs are prime targets for bad actors who can use them to launch automated attacks, steal data via hidden response codes or parameter values, or perform reconnaissance via elevated privileges for a larger, more impactful attack. No developer wants to be the person that publishes a shadow API that led to a security incident. With that in mind, here are four reasons to encourage shadow API publishers to follow the process.

  1. Visibility: Shadow APIs are invisible to your security team and that introduces a security gap. Security best practices revolve around knowing what is on the network, where the traffic is going to and coming from, and what the payload might be. Armed with the knowledge of what APIs have been published, the security team can implement an appropriate policy. Outside of the standard firewall and threat protection policies, the API can be protected using geo-fencing to restrict traffic coming from known bad regions; or they can block owners (organizations) with known bad IP addresses. On a side note, if your team is unaware of how many APIs they have, they are not alone. Research done by Aite Group indicated that many organization were unsure of how many APIs they had. For those who did have an API inventory, the average number was 620 per organization.
  2. Specification Conformance: Organizations that are moving towards API driven development methodology will often adopt an API specification framework like OpenAPI that helps guide API developers during their coding process. By definition, a shadow API is published outside of the process that may confirm it is following the specification. There are many examples where a specification validation may have avoided significant security incidents – Panera Bread, Uber, Twitter and Facebook all come to mind. The benefits of using a specification as a guideline can find and eliminate potential security gaps that may result from unpublished and hidden API endpoints, headers, parameters and response codes in use. Those elements that are discovered as non-conformant can be flagged and addressed by development. By adhering to the specification, critical elements such as access control, authentication and encryption can be validated, thereby reducing the security exposure.
  3. Sensitive Data Leakage Avoidance: Shadow APIs have access to the same sensitive information that published, secured APIs, but lack the protection because they did not follow a defined publication process. This can lead to compliance (GDPR, CCPA PCI, HIPAA, etc.) violations which can lead to regulatory fines.
  4. CLM Avoidance: Publishing a shadow API may help a developer achieve their goal, but adhering to a process may avoid a career-limiting move (CLM) by avoiding sensitive data exposure and validating that access control, authentication and encryption are enabled.  
    1. Access control: stops a bad actor from gaining access to user information (to execute an account takeover), change permissions (via a parameter such as “admin=yes”), alter data (modify dates, times, dollar values). Ensuring that API access control is implemented properly can go a long ways to avoid a security incident.
    2. Authentication: validates who you say you are via API keys, Oauth or other mechanism. Unfortunately, authentication errors abound. In some cases, API endpoints are left unauthenticated (Panera Bread), in others the API keys are hard coded or exposed in the mobile app (Trump Campaign Mobile App). If API keys are used, following best practices will help you avoid a CLM: use them for read-only functions; avoid sending them as part of your query result in a URL. Best practices recommends inserting the API key in the Authorization header. For higher value APIs, Oauth/OpenID or SAML should be used.
    3. Encryption: In a recent report from the security research team found that out of 1.2M IoT devices, which typically rely heavily on APIs, a staggering 98% of them did not use encryption. None. Given that API transactions will often include sensitive PCI or HIPAA data, encryption should be enabled by default.

The beauty of using APIs is that you can build and deploy functionality and data integrations quickly. Deploying them outside of a process as a shadow API runs the risk of negating the benefits of speed and agility by introducing a security gap. API Sentinel from Cequence Security can help organizations avoid the security gaps introduced by shadow, deprecated and non-conforming APIs with runtime inventory, risk analysis and specification conformance assessment.

Topics:
api, encryption, integration, security, shadow api, shadow it

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}