乍一看，您可能沒有注意到上述 API 響應有什么問題。但您將在下一節中看到返回此類原始數據如何導致 Rails 應用程序中的數據過度暴露。
過度數據暴露的例子
上述 API 響應會以下列方式導致過度數據暴露。
返回未過濾的數據
上述 API 響應返回未經過濾的原始數據，因此客戶端應用程序需要過濾掉有關用戶的敏感信息。客戶端應用程序只需要用戶名、個人資料和級別字段，因此返回的額外字段毫無用處。在這種情況下，返回的數據超過客戶端應用程序需要的數據就屬于數據暴露過多的情況。
如果黑客攔截此 API 響應，他們就可以查看所有敏感數據，更糟糕的是，還可以復制數據并在暗網上出售。
使用自動遞增主鍵
除非另有說明，否則 Postgres 數據庫默認使用自動遞增主鍵。由于主鍵與 URL 一起作為 ID 發送，因此任何嗅探網站流量的人都可以訪問該 ID，該 ID 是一個連續遞增的整數。它讓第三方知道數據庫的數量級。例如，如果獲取用戶數據的 API 是/user/1870，他們就知道您的數據庫已存儲了數千名用戶的數據。
在 API 響應中返回個人身份信息
PII 是可用于識別個人的任何數據，并且永遠不會顯示在網站或移動應用程序上。PII 包括個人的身份證號碼、電子郵件、信用卡詳細信息、社會安全號碼、家庭住址、駕駛執照等。在 API 響應中返回 PII 是重大數據泄露和過度數據暴露的情況。如果黑客獲得 PII 訪問權限，這可能會導致用戶在被發現后提起訴訟，進而導致小公司破產。API 安全對公司及其用戶都極為重要。
您已經看到了過度數據暴露的例子，以及 API 設計流程如何導致安全漏洞。因此，在下一節中，讓我們了解預防措施。
保護措施
下面列出了一些保護 Rails 應用程序免受過度數據暴露的方法。
不要使用自動遞增主鍵
由于主鍵在 URL 和網絡日志中作為 ID 值公開可發現，因此最好使用通用唯一標識符 (?UUID?)。 UUID 是隨機且唯一的，沒有人可以猜出數據庫的數量級。
實施服務器授權檢查
使用CanCanCan授權 gem。它定義了訪問規則，通過更改 URL 中的 ID 來限制某人查看其他人的記錄。除非獲得授權，否則用戶不能更改 URL 中的 ID 來查看其他用戶的個人資料數據。
使用數據屏蔽
數據屏蔽用于隱藏數據庫中的敏感信息（例如用戶的電子郵件），并且僅在 API 響應中顯示非敏感信息。
加密您的數據
如果您的應用必須存儲個人身份信息，則應將其全部加密。加密可保護所有敏感信息免遭窺探。通過加密，即使攻擊者獲得了您的數據庫或 API 響應的快照，他們也無法理解數據。
不要返回未經過濾的原始 API 響應
設計 API 時，請使用最小權限原則，僅返回用戶需要的數據。將未經過濾的原始數據返回給移動或 Web 應用程序絕不是一個好主意。檢查每個 API 響應，并在將數據呈現給客戶端之前在服務器上過濾掉用戶不需要的數據。
不要存儲敏感的 PII 數據
使用第三方存儲敏感數據。例如，對于所有信用卡詳細信息，您都應將其存儲在Stripe等第三方中。在這種情況下，信用卡詳細信息在任何情況下都不會顯示在任何 API 請求中，因為您不會將它們存儲在自己的數據庫中。
您應該根據本文中學到的知識評估您的 API 是否安全。如果不安全，您應該考慮使用上述一些預防措施。
結論
在本文中，您了解了過度數據暴露是什么、數據敏感度級別，以及在設計 Rails API 時可能導致過度數據暴露的示例。最后，您了解了需要采取哪些措施來防止過度數據暴露。
數據是任何公司都應不惜一切代價保護的重要資產。確保用戶數據安全可保護您的公司免受訴訟造成的損失并保護公司形象。對于 API 請求，您不應默認返回數據庫中存儲的所有字段。數據安全有助于客戶信任您的企業并向其提供數據。