Consultas a APIs de gestión, con token, páginas y certificados

Una API de gestión suele pedir un token en la cabecera Authorization, con el esquema Bearer. Ese token es una credencial, y lo primero que se mira en un script es de dónde sale. Lo correcto es que no esté escrito en el código sino en el entorno o en un almacén de secretos, para que el archivo pueda compartirse y revisarse sin exponer nada.

Abre descarga_hallazgos.py y busca la línea que asigna el token que de verdad se usa.

requests.get acepta el argumento verify. Por defecto la biblioteca comprueba que el certificado del servidor es válido y lo emitió una autoridad de confianza. Poner verify=False quita esa comprobación. Suele aparecer cuando el servicio usa un certificado interno que el equipo no reconoce y alguien «lo arregla» por el camino corto. La solución correcta es indicar la autoridad interna, no apagar la validación.

Las APIs que devuelven listas largas las entregan por páginas: cada respuesta trae un trozo, el total y algún campo que dice cómo pedir el siguiente trozo. Un script que lee una sola respuesta cree que tiene la lista entera. Para saber si hay más hay que mirar la respuesta, no el código.

Abre respuesta-pagina-1.json y revisa qué campos acompañan a la lista.

El script pide 100 resultados por página y lee solo la primera respuesta. La respuesta dice cuántos hallazgos abiertos hay en total. La diferencia entre el total real y los que el informe cuenta es la parte de la realidad que nadie ve, y no aparece en ningún mensaje de error porque la petición funcionó.

Compara salida-del-script.txt con respuesta-pagina-1.json.

Comentar una línea no la borra: sigue en el archivo, en su historial de versiones y en cada copia que alguien haya hecho. Una línea que parece contener un token, aunque sea de pruebas y aunque esté comentada, se trata como credencial expuesta. El paso eficaz es dejar el token sin validez y emitir otro, no solo quitar la línea.