Noté que algunos sitios web hacen esto y no estoy seguro de si esto es normal o no. Así, por ejemplo, en algunos sitios web, entro en configuración y puedo crear una clave de API que estará visible en texto sin formato. Además, parece que muchas solicitudes HTTP tienen una clave API visible en la URL. Algo como esto "https://www.myWebsite/user?apiKey=\(apiKey)" . Cualquier apreciación sobre esto es apreciada.
"Normal" puede ser la elección incorrecta de las palabras para su pregunta. La verdadera pregunta es ... "¿Es seguro?"
Rompiendo la pregunta en diferentes partes, aquí tengo mi respuesta:
1. ¿Es seguro que un sitio me proporcione una clave API?
No es un problema proporcionarle su propia clave API, ya que es su clave su . Esto es cierto siempre y cuando la página se sirva utilizando https. Servir la página sin cifrar permitiría que cualquier persona entre usted y el servidor web también vea su clave API.
2. ¿Se puede pasar una clave API a través de la URL y seguir siendo secreta?
No. Pasar una clave API a través de la URL significa que la clave se almacena en los registros del servidor, en el historial de un navegador, visible para las extensiones del navegador, copiado / pegado accidentalmente por un usuario, etc. Ya no es un secreto. Esto es cierto incluso si la página se sirve a través de https.
3. ¿Una clave de API debe mantenerse en secreto?
Esta pregunta puede ser buena para explorar. Tal vez el servicio al que te refieres proporciona una clave API y una clave secreta. La clave API se puede exponer a través de la URL, pero la clave secreta debe usarse para calcular un encabezado determinado que también debe acompañar la solicitud.
Otro ejemplo podría ser una API que se espera que se llame a través de JavaScript. En este caso, cualquier cosa en el código será expuesta al cliente. Nuevamente, el servicio proporcionado puede esperar que una clave que se derive de su clave secreta se pase a través del servicio.
De forma alternativa, tal vez ninguna de las claves sea secreta, pero el servicio utiliza la lista de direcciones IP para asegurar que el servidor solo pueda utilizar las claves. También podrían realizar la comprobación del nombre de host y permitirle especificar nombres de host válidos en su cuenta para los que se permite el uso de la clave.
Summary
En última instancia, la técnica que un servicio elige utilizar para proteger sus claves y claves secretas debe coincidir con la necesidad de mantenerlos en secreto o la necesidad de proteger a los usuarios no autorizados de llamar al servicio. En algunos casos, no importa si alguien usa sus llaves para llamar al servicio.
Es estándar hacer que la clave api sea visible para ti. Y al final del día, siempre puede extraer la clave de su navegador sin importar cómo esté protegida. En cuanto a que menciona "texto sin formato", no es realmente posible cifrar de manera significativa la clave si eso es lo que quiere decir. Al final del día, es poco probable que abusen de su clave de API, ya que realmente le pertenece. La única desventaja de tenerla en la URL es una pequeña posibilidad de que le envíes la clave a alguien como parte de un enlace.
Lo que es muy sospechoso de tu ejemplo es que es http: y no https :. Debe NUNCA enviar claves, contraseñas o cualquier cosa sensible a través de http. No estoy seguro de si esto es parte de la pregunta o el error de su parte.
Intentaré responder tu pregunta acerca de la "normalidad" de esta práctica, pero requiere cierta configuración. Supongamos que está sirviendo una página HTML, que realiza una solicitud AJAX a alguna API de terceros. Se ha registrado en un plan con ellos y le proporcionan una clave API.
Cualquiera que busque en la fuente de su página HTML puede encontrar la clave API y usarla para sus propios fines. La recomendación habitual es que su página HTML realice la solicitud no a la API externa, sino a su servidor, donde ha implementado una API proxy. Está agregando la clave API a la solicitud, envíelo a la API externa y devuelva la respuesta al navegador. De esa manera, su clave de API se mantendrá secreta mientras esté usando https y nadie entre en su servidor.
Sin embargo, ¿qué has logrado en este momento? Usted ha creado el equivalente de una retransmisión de correo abierto. Al igual que los spammers utilizan una retransmisión de correo abierto para enviar sus correos masivos sin pagar por un servicio legítimo, cualquiera puede usar su servidor como proxy para la API de terceros. En otras palabras: en lugar de llamar (digamos) directamente a Google Maps, ellos están llamando a su servidor y usted los está llamando a ellos con su clave API secreta.
En este punto, es posible que también haga pública su clave de API, porque entonces al menos ahorrará el tráfico generado por cientos de sitios no relacionados que lo utilizarán como un proxy conveniente. Este puede ser el pensamiento detrás de la práctica de no mantener en secreto las claves API de terceros, ya que le ahorra tráfico a costa de aumentar los costos de su plan API de terceros.
El problema de seguridad ahora se ha convertido en una decisión de negocios: tal vez la API externa tenga un generoso nivel gratuito y no esté pagando realmente las solicitudes "no deseadas". O tal vez esté pagando esas solicitudes, pero el valor comercial de su servicio real es mucho menor que esos costos. Tal vez poner una capa de autenticación frente a su servicio lo haría tan incómodo para sus usuarios, que está perdiendo negocios. O quizás (este es mi favorito) ha diseñado su aplicación web de manera que el resultado de la solicitud a la API externa sea relativamente inútil fuera del contexto de su aplicación. Supongamos que está obteniendo indicaciones a través de Google Maps desde el punto X a su empresa (y no a un punto Y arbitrario).
Si no desea resolver este problema a nivel empresarial, sino profundizar en la seguridad, entonces (por lo que veo) tiene que poder distinguir entre las solicitudes deseadas y no deseadas. Si las solicitudes van directamente desde el navegador de los usuarios a la API externa, entonces no hay manera de hacerlo. A menos que necesite que todos sus usuarios proporcionen sus propias credenciales para acceder al proveedor de API externo, lo cual no es realista en la mayoría de los casos de uso (y puede ser un problema de seguridad desde la perspectiva de sus usuarios).
Al final del día, debe tener las solicitudes en su servidor y filtrar las solicitudes no deseadas allí. Cómo implementas eso depende de tu aplicación.
Lea otras preguntas en las etiquetas account-security api