Today we are excited to announce a pretty big new capability at JumpWire - our HTTP proxy is available in beta!

Now the JumpWire proxy engine can be deployed on the edge of any API or SaaS integration to automatically secure data in HTTP payloads. By securing data as it moves across API endpoints, organizations can guarantee that sensitive information is not at risk of being leaked or stolen, and ensures they are staying compliant with their InfoSec program.

Bruh what’s Jumpwire?

JumpWire automatically adds data security to any application without changing a single line of code. It operates at the application level, applying encryption and inspection to individual fields in data payloads. Security measures such as TLS and full disk encryption operate on bytes - they can’t differentiate between confidential information (such as customer PII) and public information (such as stock tickers).

Not JumpWire, but just as cool

In contrast, applications typically exchange typed data, and companies need to ensure they handle different classifications of data appropriately. JumpWire is the only self-hosted platform that doesn’t require partitioning of data or using complex enclaves for applications to properly process sensitive information.

The DB proxy is already awesome, why HTTP?

APIs are eating the world! Software and services are increasingly being delivered through APIs. A typical banking app, for example, might leverage a dozen or more services on the backend delivered through APIs. Mobile applications communicate with their own backend through APIs. And microservice architectures often make inter-service calls through internal APIs. All of these are using HTTP to exchange information in request and response payloads.

As a result APIs are a common entry and exit point for data to move between applications. While existing API security measures have been designed to protect applications against attackers (think Authnz/WAF/DPI), none have focused on securing the payload data of an HTTP request or response. It is difficult to audit whether sensitive information is part of the payload, and enforce data handling based on classification, without writing specialized code into the API application directly.

There is a rise in “shadow” or “dark” data moving through APIs as well - information being shared with third parties through their APIs integrated into backend applications. This nomenclature refers to the fact that most organizations today are blind to this activity and reliant on developers to self-govern the data exchange. As more and more companies deliver their products through APIs, these programmatic interfaces represent significant risks for data leaks through third-party vendors.

An elegant solution

JumpWire’s newest capability is a data-aware HTTP proxy for classifying data and enforcing handling policies in real-time. It inspects the properties of an HTTP request/response payload, determines if those properties need special handling, and transforms their values according to policies. The proxy can be deployed on the API edge, intercepting data before a backend application processes the request.

For example, if a mobile application is collecting customer PII (such as names and social security numbers) and sending them to a server via HTTP, JumpWire can encrypt those values before the server processes and stores the information. This ensures that sensitive information can’t be leaked, even if the request is logged by the server or an attacker gains access to the database.

HTTP proxy encrypts PII fields

Ok this sounds great, but at some point the application will need the original data — let’s say we want to send an email to our customer addressing them by their name. Good news, everyone! The HTTP proxy is 100% compatible with JumpWire’s database proxy! So our email service can query the encrypted name out of the database, JumpWire will decrypt the name in real time, and the personalized email content can be drafted without any special code.

HTTP proxy encrypts PII fields, DB proxy decrypts for sending email

This flexibility of mixing HTTP and database proxies supports a wide variety of application architectures. In the example below, we’ve added a third-party service for verifying the identity of a customer (KYC). By using the HTTP proxy for the outbound HTTP request, we can decrypt the PII fields just before they are sent to the KYC service.

HTTP proxy encrypts on ingress, decrypts on egress only when explicitly allowed

This has the effect of transforming the entire application architecture into a secure data vault! Sensitive information stays encrypted in transit, in use and at rest, and is only encrypted when needed.

If you are interested in using the HTTP proxy please contact us! We are onboarding new customers via invitation while this feature is in beta.

• Ryan