I need to send sensitive data to a third-party public API, and a site-to-site VPN is not available. Does HTTPS provide enough protection, or would mTLS add something useful?
Is mTLS worth adding if the API already uses HTTPS?
Answers
They solve different parts of the problem. HTTPS with properly validated TLS encrypts traffic in transit and lets your client verify the server. With mTLS, the server also checks a client certificate, so it can verify which client is connecting. That is useful if the provider supports it and you need certificate-based client authentication, but it does not make the traffic more encrypted than HTTPS already does.
Reply to this answer
First ask the provider what authentication and transport options their API supports. If they don't support mTLS, you can't add it just on your side. A well-secured HTTPS API with its supported authentication method can be appropriate. Check how credentials are stored and rotated, use a current TLS configuration, and avoid putting secrets or sensitive payloads in logs.
Reply to this answer
mTLS can be an extra hurdle if an API token is exposed, but only if the provider ties the client certificate to your account or credentials. It also brings certificate issuance, renewal, and revocation to manage. I'd choose it when the provider supports it and the stronger client identity fits your risk requirements, not just because the endpoint is public.
Reply to this answer
If your concern is that the API provider itself should not be able to read the data, mTLS won't address that. It authenticates the connection between client and server, while the server still receives the readable payload. End-to-end encryption may be relevant for that threat model, but it needs the recipient to handle the encrypted data and a sound key exchange.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions