is passing key via get url param - isn't security risk

[surapuramakhil]

https://github.com/tavily-ai/tavily-mcp?tab=readme-ov-file#remote-mcp-server

I was going trough tavily-ai -> docs recommend passing api key in URL parameters, concerned on logging of key, and also dump of url string params

[surapuramakhil]

When passing a sensitive "key" (like an API key, API secret, or auth token), HTTP Headers are the industry standard and ideal practice.

Here is the security breakdown of all three methods, including why one reigns supreme and why others pose severe security risks.

1. HTTP Header (Ideal Practice)

Example: Authorization: Bearer your_api_key or X-API-Key: your_api_key

This is the most secure and architecturally clean way to transmit access keys.

• Pros:

  • Encrypted in Transit: Like the rest of the request, headers are fully encrypted end-to-end via TLS/HTTPS.

  • Not Logged by Default: Web servers (Apache, Nginx), reverse proxies, and API gateways do not log HTTP headers in their standard access logs.

  • Separation of Concerns: Keeps authentication metadata separate from the actual data payload.

  • No Referer Leakage: If your page links to an external site, headers are not passed along to the third party.

• Cons:

  • Slightly More Complex to Test: You cannot simply paste the URL into a browser address bar to test it; you must use tools like cURL, Postman, or frontend JavaScript.

2. POST Request Body (Acceptable, but Not Ideal for Keys)

Example: POST /api/v1/resource with a JSON body {"api_key": "your_api_key"}

Note: If you put the key in the URL of a POST request (e.g., POST /api?key=xyz), it inherits all the fatal flaws of a GET URL parameter.

• Pros:

  • Encrypted in Transit: Fully protected by TLS/HTTPS.

  • Not Logged in URL History: It won't show up in browser histories or standard server access logs.

• Cons:

  • Data and Auth Mixing: It forces you to mix operational data (the payload) with authentication credentials.

  • Restricts HTTP Methods: If you need to perform a simple GET request to fetch data, you are forced to use a POST request just to hide the key in the body. This violates RESTful API design principles.

3. GET URL Parameter / Query String (Worst Practice)

Example: GET [https://api.example.com/data?api_key=your_api_key](https://api.example.com/data?api_key=your_api_key)

Never use this for sensitive, long-lived keys or credentials.

• Pros:

  • Easy to Test: You can share a link, click it, and it works directly in any browser.

• Cons (Severe Security Risks):

  • Server Log Exposure: Web servers log the entire URL by default. Your API keys will sit in plain text inside Nginx/Apache logs, SIEM systems, and ELK stacks.

  • Browser History: The key is saved in the user's browser history. Anyone with access to the device can retrieve it.

  • Referer Header Leakage: If the page makes a request to a third-party asset (like an image or an external link), the entire URL—including the API key—is sent to that third party via the Referer header.

  • Over-the-shoulder Visibility: The key is visible to anyone looking at the user's screen.

Quick Reference Summary

Method | Encrypted via HTTPS? | Hidden from Server Logs? | Hidden from Browser History? | Ideal for Keys? -- | -- | -- | -- | -- HTTP Header | Yes | Yes | Yes | 💎 Yes (Best Practice) POST Body | Yes | Yes | Yes | ⚠️ No (Flawed Architecture) GET URL Param | Yes | ❌ No | ❌ No | ❌ Never (Dangerous)

Verdict & Implementation Tips

To implement HTTP Headers correctly:

1. Use the standard Authorization header whenever possible (e.g., Authorization: Bearer <key>).

2. If using a custom header, prefix it clearly (e.g., X-API-Key: <key>).

3. Enforce TLS/HTTPS. Headers are only secure if the connection is encrypted. If a request drops down to HTTP, the header is sent in plain text.