Security Considerations for HTTP Requests

When our C++ applications make HTTP requests to servers, there are a number of security considerations to keep in mind to protect our application and users.

Always use HTTPS for sensitive data

If our application sends or receives sensitive data like passwords, API keys, personally identifiable information, etc., the requests and responses must be encrypted. Use https:// URLs instead of http:// to enable SSL/TLS encryption of the traffic.

Validate server certificates

When using HTTPS, the server's SSL certificate should be validated to ensure we're communicating with the genuine server and not an imposter. By default, cpr validates certificates using the CA (Certificate Authority) certificates installed on the system.

On Windows, cpr uses the Windows Certificate Store. On Unix-based systems, it uses the directory specified by the SSL_CERT_DIR environment variable, or /usr/lib/ssl/certs as a fallback.

We can specify custom CA certificates to use instead:

1#include <cpr/cpr.h>
2
3int main() {
4  cpr::Url URL{"https://www.example.com"};
5
6  cpr::SslOptions sslOpts{
7    .ca_info = "path/to/ca-bundle.crt"
8  };
9
10  cpr::Response r = cpr::Get(URL, sslOpts);
11}

URL-encode user input in request parameters

If we're including user input in the request URL or parameters, it must be properly URL-encoded to prevent injection attacks. The cpr functions handle this for us when we use the cpr::Parameters type. But if we're constructing URLs manually, we need to be careful.

Sanitize and validate request data

Any data included in requests, whether in the URL, headers or body, should be treated as untrusted input. Validate it matches the expected format before processing it further or including it in SQL queries, shell commands, file paths, etc. Common validations include:

• Checking data type and length
• Ensuring numeric values are within valid ranges
• Stripping tags and special characters to prevent cross-site scripting (XSS)
• Using parameterized queries or escaping values included in SQL

1. Implement rate limiting

To protect the servers we communicate with and prevent abuse, it's a good practice to limit the rate at which our application makes requests. Implement exponential backoff to progressively increase the delay between retries if requests are failing.

Be a good citizen and respect the X-RateLimit headers included in responses, which tell us the maximum number of requests allowed per time period.

By following these best practices, we can help ensure our applications handle HTTP communication safely and securely.