你不能。

这是因为浏览器的设计目的就是:提供内容。但你可以让它更难下载。

方便的“解决方案”

我会把我的视频上传到第三方视频网站，比如YouTube或Vimeo。他们有很好的视频管理工具，优化设备的播放，他们努力防止他们的视频被撕掉，而你却没有付出任何努力。

解决方案1、禁用“右键单击”

你可以禁用上下文菜单事件，也就是“右键单击”。这将防止你的常规skiddie公然撕扯你的视频右击和另存为。但他们可以禁用JS，绕过这个问题，或者通过浏览器的调试器找到视频源。另外，这是糟糕的用户体验。在上下文菜单中有很多合法的东西，而不仅仅是另存为。

解决方案2，视频播放器库

使用自定义视频播放器库。它们中的大多数实现了视频播放器，可以根据您的喜好定制上下文菜单。你不会得到默认的浏览器上下文菜单。如果他们确实提供类似于另存为的菜单项，你可以禁用它。但同样，这是一个JS的解决方案。弱点类似于解决方案1。

解决方案3,HTTP直播

另一种方法是使用HTTP Live Streaming提供视频。它本质上是把视频切成块，然后一个接一个地播放。这就是大多数流媒体网站提供视频的方式。因此，即使你设法另存为，你只保存了一部分，而不是整个视频。收集所有的块并使用一些专用软件将它们缝合起来需要更多的努力。

解决方法4，在画布上作画

另一种技巧是在<canvas>上绘制<video>。在这种技术中，使用一些JavaScript，您在页面上看到的是一个<canvas>元素从隐藏的<video>渲染帧。因为它是一个<canvas>，上下文菜单将使用一个<img>的菜单，而不是一个<video>的。你会得到另存图像，而不是另存视频。

解决方案5,CSRF令牌

您还可以利用CSRF令牌。您可以让服务器在页面上发送一个令牌。然后使用该令牌获取视频。您的服务器在提供视频之前检查它是否是一个有效的令牌，或者获得HTTP 401。这个想法是，你只能通过有一个令牌来获得一个视频，你只能从页面来，而不是直接访问视频url。

+1简单和跨浏览器的方式: 你也可以用css z-index和不透明度把透明的图片放在视频上。 这样用户将在上下文菜单中看到“另存图片为”而不是“保存视频”。

我们可以通过隐藏上下文菜单来让这变得不那么容易，就像这样:

<video oncontextmenu="return false;"  controls>
  <source src="https://yoursite.com/yourvideo.mp4" >
</video>

尝试禁用下载视频选项

<video src="" controls controlsList="nodownload"></video>

PHP将html5视频标记和一个会话一起发送，其中键是一个随机字符串，值是文件名。

ini_set('session.use_cookies',1);
session_start();
$ogv=uniqid(); 
$_SESSION[$ogv]='myVideo.ogv';
$webm=uniqid(); 
$_SESSION[$webm]='myVideo.webm';
echo '<video autoplay="autoplay">'
    .'<source src="video.php?video='.$ogv.' type="video/ogg">'
    .'<source src="video.php?video='.$webm.' type="video/webm">'
    .'</video>'; 

现在PHP被要求发送视频。PHP恢复文件名;删除会话并立即发送视频。此外，所有“无缓存”和mime类型的头必须存在。

ini_set('session.use_cookies',1);
session_start();
$file='myhiddenvideos/'.$_SESSION[$_GET['video']];
$_SESSION=array();
$params = session_get_cookie_params();
setcookie(session_name(),'', time()-42000,$params["path"],$params["domain"],
                                         $params["secure"], $params["httponly"]);
if(!file_exists($file) or $file==='' or !is_readable($file)){
  header('HTTP/1.1 404 File not found',true);
  exit;
  }
readfile($file);
exit:

现在，如果用户复制url在一个新的选项卡或使用上下文菜单，他将没有运气。

我发现了一个类似问题的好答案，使用PHP而不是JavaScript以获得更好的安全性。

我想使用浏览器的默认播放器在用户的浏览器中播放test.mp4(就像在Web页面上单击了URL/test.mp4一样)，但需要密码，该密码由用户提供或由软件内部提供。

下面是这个想法的一个简要概述。它开始于用户去(运行)一个我写的叫做secure.php的程序来播放test.mp4。

文件test.mp4位于一个子目录("secureSubdirectory")中，该子目录包含一个包含"Require all denied"的.htaccess。这立即阻止了任何通过URL的直接访问。

当secure.php运行时，它提供一个密码(或向用户查询密码)，然后对自己执行一个包含密码的POST，使用一个salt，使用PHP命令验证它:

$Hash=base64_encode(hash_hmac("sha256",$Pwd,$Salt,true));
$HashesAreSame=hash_equals($Hash,$GoalHash);

然后测试test.mp4是否存在，并执行以下PHP代码将test.mp4文件作为字节流返回给用户的浏览器:

header("Content-Type: video/mp4");
echo file_get_contents("secureSubdirectory/$path");
exit;

视频和预期的一样。如果我然后右键单击显示视频的页面并尝试保存视频，结果文件将只包含一个错误字符串，如“错误:密码未找到”，因为test.mp4是使用普通的secure.php URL查询的，而不是使用正确的密码通过POST。

当然，您可以使用浏览器调试工具的Network选项来获得响应有效负载(视频字节)，但是如果浏览器提供了阻止访问调试工具的选项，那么PHP程序或.htaccess文件就可以阻止这种情况。

我无法想象失败的案例，但如果存在的话我会非常感兴趣，因为简单而完美的授权是非常罕见的事情。(请注意，由于这种方法依赖于密码，因此将其与用户关联并不是一种安全的身份验证方式，因为用户可能会意外或故意地发布或共享密码。)