我正在开发一个 iOS 应用程序，它将为每个 URL 请求发送用户的用户名和密码。目前，只是为了简单起见，直到它准备好启动，用户名和密码在 GET 请求中通过 HTTPS 传递，如下所示。
https://www.example.com/api/login.php?username=user&password=pass
HTTPS 保护传输参数，但我知道这样做的安全问题是 URL 可以存储在浏览器历史记录和任何服务器日志中。
我的问题... 用户名和密码是否会存储在任何历史记录或日志中？
Authorization: Basic aHR0cHdhdGNoOmY=
编辑：我已经知道 base64 可以很容易地反转......这不是我要问的。我只是询问将用户名和密码放入 HTTPS GET 参数与标头的安全性。
更新：我现在对登录端点使用基本身份验证，并返回一个 JSON Web 令牌以用于此后的所有请求。
用户名和密码是否会存储在任何历史记录或日志中？
通常不记录授权标头，但当然，可以配置应用程序或服务器来记录这些数据。因此检查您的设置。
至于存储在历史记录中：在浏览器的情况下，此类凭据不会存储在历史记录中，但可能会像 cookie 一样存储并在访问站点时自动发送。然而，由于您使用的不是浏览器，而是您自己的应用程序，因此您可以自行决定如何管理这些信息。
您应该在第一次交换后使用临时令牌，以避免在每个请求中传输真实凭证。因此，您的应用程序只需要记住临时令牌，而不是完整的凭据。
是的，将它放在标题中比放在 url 中更好：
我不完全确定 OP 是否直接询问该方案在使用标头后是否完全安全：
我的问题...
...或者，如果问题仅与客户端日志记录有关，而不是整体安全：
用户名和密码是否会存储在任何历史记录或日志中？
但是，假设问题是整体安全性，我想指出，尽管 OP 使用的是 HTTPS，但我的理解是，现在通过每个请求传输凭据被认为是不好的，因为 MITM 重放攻击仍然是可能的（即使HTTPS 被使用）。因此，即使在使用 HTTPS 时，也应该优先使用 JWT 等令牌方案，而不是在任何请求时使用基本身份验证。
这安全吗？
不是特别。Base64 编码可以很容易地反转。
用户名和密码是否会存储在任何历史记录或日志中？
也许，从可用信息中无法判断。当然，数据可能会被记录在中间人攻击中。
这实际上归结为一个风险问题。这是好习惯吗，绝对不是。它是否适合财务/健康记录，当然不适合。几乎可以肯定的是，在测试新产品时是否足够好，特别是如果您没有记录实时数据并且会在上线之前重置数据库。