是否需考虑数据库行/文档级安全？社交网络越权风险问询

Great question—this is exactly the kind of authorization gap that can turn a seemingly solid social app into a privacy nightmare. Let’s break down how to fix this properly:

Core Problem #

Right now, your app is only checking if the hacker’s ID exists in the target user’s friends array. But if an attacker can modify that array directly (whether via API exploits, database access, or client-side tampering), they can bypass your intended mutual-friend rule entirely. The root issue is that you’re relying on a single, mutable data point instead of verifying a bidirectional, authorized relationship.

Fixes to Implement #

1. Enforce Bidirectional Friendship Validation #

Never trust a single friends array alone. For any content access request, you need to verify two things:

• The current user’s ID is present in the target user’s friends array
• AND the target user’s ID is present in the current user’s friends array

In code (using SQL as an example), this might look like:

-- Check if user A and user B are mutual friends
SELECT EXISTS (
    SELECT 1 FROM friends 
    WHERE user_id = ? AND friend_id = ?
) AND EXISTS (
    SELECT 1 FROM friends 
    WHERE user_id = ? AND friend_id = ?
);

If either check fails, reject the access request—even if one side’s array was tampered with.

2. Lock Down Friendship Write Permissions #

The biggest mistake you can make is letting clients directly modify friends arrays. All friendship changes must go through a controlled, server-side workflow:

• When User A sends a friend request, store it as a pending request (not a direct friend addition)
• Only when User B explicitly accepts the request should your backend atomically update both users’ friends arrays (either both updates succeed, or neither do—no partial additions)
• Delete any API endpoints that allow direct edits to friends arrays; all modifications must route through request/accept logic

3. Use a Dedicated Friendship Table (Instead of Embedded Arrays) #

If you’re using a NoSQL database like MongoDB, avoid embedding friends directly in user documents. Instead, create a separate friendships collection where each entry tracks a relationship between two users, plus a status (e.g., pending, active).

For example, a valid mutual friendship would require either:

• Two entries: one for user_a -> user_b and one for user_b -> user_a, both marked active
• Or a single entry with a flag indicating the relationship is mutual

This makes tampering harder—an attacker can’t just modify one user’s document to gain access; they’d have to create a matching entry in the friendship table, which your backend logic blocks.

4. Do All Authorization Checks on the Server #

Never rely on client-side checks to restrict access. A hacker can easily modify client code to skip UI-level restrictions. Always validate the mutual friendship before returning any private content from your backend API.

5. Add Anomaly Detection #

Log all friendship changes (who initiated, who accepted, timestamps) and set up alerts for suspicious activity—like a user’s friends array growing by 10+ unknown IDs in an hour. You can even auto-rollback unauthorized changes if you detect them quickly.

Final Thought #

The key principle here is: authorization should verify relationships, not just single data points. By making friendship validation bidirectional and locking down how those relationships are created, you’ll eliminate this critical vulnerability.

内容的提问来源于stack exchange，提问作者CodyBugstein