What are the security risks of using an HTTP proxy for API requests in the backend?

Question

I am using a proxy to request API related to payment in the backend. API proxy requests are made using the HTTP protocol. User-sensitive data is delivered when API requests are made.

In the case of HTTP requests, I understand that they are delivered in unencrypted plain text, so I am worried that there is no security risk.

I wonder if my concern is correct or if there are any other security risks.

Vevine

Answer 1

Using an HTTP proxy for API requests, especially for sensitive operations like payments, does pose several security risks.

[ Client ] --(HTTP)--> [ Proxy Server ] --(HTTP)--> [ Payment API ]
                         |                        |
                      Unencrypted             Unencrypted
                      Data Transfer           Data Transfer

Since HTTP is unencrypted, data transferred between your server and the proxy, and between the proxy and the API, can be intercepted by attackers.

Attackers could potentially intercept and alter the data being sent or received, leading to fraudulent transactions or data theft (Man-in-the-middle attack).

Sensitive information like credit card numbers, personal details, etc., could be exposed if the proxy or network is compromised.

And without encryption, there is no easy way to make sure the data has not been tampered with during transit.

Using HTTP may violate regulatory requirements, for instance Payment Card Industry Data Security Standards (PCI DSS).

---

A safer setup would be to switch to HTTPS for all communications. That encrypts data in transit, making it much more secure. HTTPS uses SSL/TLS to provide encryption, authentication, and integrity.

[ Client ] --(HTTPS)--> [ Proxy Server ] --(HTTPS)--> [ Payment API ]
                         |                        |
                      Encrypted               Encrypted
                      Data Transfer           Data Transfer

• Configure your server and proxy to use HTTPS.
• Obtain SSL/TLS certificates for your domain.
• Update your backend code to use HTTPS URLs for API requests.

For instance, using Go:

// Example in Go: Sending an HTTPS request
package main

import (
    "crypto/tls"
    "net/http"
)

func main() {
    // Configure HTTPS transport
    tr := &http.Transport{
        TLSClientConfig: &tls.Config{InsecureSkipVerify: false},
    }
    client := &http.Client{Transport: tr}

    // Make HTTPS request
    resp, err := client.Get("https://your-proxy-server.com/payment-api")
    // Handle resp and err
}

---

Note that I often see, in enterprise, HTTP flux between an HTTPS proxy and backend services.

It is usually due to a design choice in the network architecture, known as SSL/TLS termination at the proxy level.

[ Client ] --(HTTPS)--> [ HTTPS Proxy ] --(HTTP)--> [ Backend Service ]
                          | SSL/TLS termination
                          | Decryption of data

SSL/TLS encryption and decryption are resource-intensive. By offloading this task to the proxy, backend services are relieved from this overhead, improving overall performance.

But the main reason: by handling SSL/TLS at the proxy, you can manage certificates, ciphers, and SSL/TLS protocols in one place, rather than across multiple backend services.

Once the traffic is decrypted at the proxy, it enables various security and monitoring tools to inspect and filter the traffic more effectively (inside an intranet).

Backend services can be configured more simply, without the need for SSL/TLS setup, which can be complex and error-prone.

And, with this model, I see a reverse-proxy like F5, which allows to:

• define VIP (Virtual IP like https://myservice.mycompany.com)
• define backend server (my.server.my.internal.domain:8080)
• redirect the VIP to the backend

Warning: That architecture assumes a secure internal network where the HTTP traffic between the proxy and backend services is less exposed to external threats.
However, this does expose a risk from internal threats. If the internal network is compromised, unencrypted HTTP traffic can be intercepted.

---

That would not be a good model for certain types of data, like payment information or personal data, regulations might require end-to-end encryption, which means keeping the data encrypted all the way to the backend service.

That means, especially where end-to-end encryption is required, SSL/TLS passthrough is used. Here, the proxy does not decrypt the traffic; instead, it passes the encrypted data directly to the backend service, which then handles the decryption.

[ Client ] --(HTTPS)--> [ HTTPS Proxy ] --(HTTPS)--> [ Backend Service ]
                          | SSL/TLS passthrough
                          | No decryption of data

In such cases, backend services must be capable of handling SSL/TLS encryption and decryption. That setup enhances security but increases the complexity and resource usage on the backend services.

Gibeon