如何实现私有图片仅在指定网站显示？禁止直接访问图片src

Absolutely, this is totally feasible! There are several solid ways to lock down your private images so they only load on your website, even if someone copies the direct src link. Here’s how to do it, organized by ease of implementation and security strength:

1. Referrer Policy (Quick & Basic Protection) #

This is the simplest approach for blocking casual hotlinking or direct URL access. The idea is to configure your image server to only serve images when the request comes from your domain (the "referrer").

Implementation Steps: #

• On your image server: Set the Referrer-Policy HTTP header to restrict requests without a valid referrer from your site. For example:
  • Nginx config:

    add_header Referrer-Policy "strict-origin-when-cross-origin";
    

  • Apache config:

    Header set Referrer-Policy "strict-origin-when-cross-origin"
    

• On your <img> tags: Add the referrerpolicy attribute to enforce the policy at the client level:

  <img src="https://your-image-host.com/private-photo.jpg" referrerpolicy="strict-origin-when-cross-origin" alt="Private Image">
  

When someone copies the URL and opens it in a new tab, the browser won’t send your domain as the referrer—so your server can reject the request with a 403 Forbidden error.

Note: Some browsers might strip the referrer in edge cases, so this is great for basic protection but not bulletproof on its own.

2. Signed, Time-Limited URLs (Stronger Security) #

For robust protection, generate unique, expiring URLs for each image request. Even if someone copies the link, it’ll stop working after a short window (like 5-10 minutes).

Implementation Steps: #

• Backend logic: When your website serves a page with an image, generate a signed URL that includes:
  • The image path
  • An expiration timestamp
  • A cryptographic signature (using a secret key only your server knows)
• Image server validation: When a request comes in, check if the timestamp is still valid and verify the signature. If either fails, return a 403 error.

Example pseudocode (Node.js-style):

const crypto = require('crypto');
const secretKey = "your-super-secret-key-keep-it-safe";

// Generate signed URL when rendering the page
const imagePath = "/private-image.jpg";
const expires = Date.now() + 5 * 60 * 1000; // Valid for 5 minutes
const signature = crypto.createHmac("sha256", secretKey)
  .update(`${imagePath}${expires}`)
  .digest("hex");

const signedUrl = `https://your-image-host.com${imagePath}?expires=${expires}&signature=${signature}`;

// Insert into your HTML
<img src="${signedUrl}" alt="Private Image">

On your image server, you’ll decode the expires and signature parameters, recompute the signature with your secret key, and compare it to the provided one. If they match and the time hasn’t passed, serve the image.

3. Session-Tied Token Authentication (User-Specific Access) #

If you want to tie image access to a user’s active session on your site, use a token linked to their session ID.

Implementation Steps: #

• When a user logs in: Generate a unique token and store it in their server-side session or secure cookie.
• Image URLs: Include this token as a query parameter in the image src.
• Server validation: When the image is requested, check if the token exists in an active session. If not, reject the request.

This way, copied URLs will only work if the user’s session is still active (and they’re using the same browser). If they log out or their session expires, the URL becomes useless.

4. Combine Methods for Maximum Security #

For the strongest protection, pair Referrer Policy with Signed URLs. This covers both cases where the referrer is missing (new tab access) and where someone might try to reuse an old URL after it expires.

Key Caveats: #

• No method is 100% unbreakable (e.g., advanced users could spoof referrers or capture a signed URL before it expires). But these approaches make it extremely difficult for casual users and most malicious actors.
• Never store private images in a public directory/bucket that bypasses your validation checks.

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