* 经常URL的保护仅仅是连接到该页面的链接不出现在未授权的用户面前.然而,一个有动机的、熟练的或者仅仅是幸运的黑客可能会找到并访问这些网页 , 调用这些功能并查看数据.在应用程序中，通过隐匿来实现安全并不足以保护敏感的功能和数据. 在请求敏感功能前，必须先执行访问控制程序以确定用户是否被授权.
受影响的环境
所有的WEB应用程序都很容易受到“失效的URL访问限制”的攻击
弱点
针对这个弱点的主要攻击方法是“暴力浏览”,这种方法通过猜测链接以及暴力手法来找到没有受到保护的页面. 应用程序经常允许对访问控制的代码进行扩展, 这导致一个复杂的访问控制模型以至于开发人员和安全专家都难以理解. 这种复杂性将产生类似的错误使一些页面失去控制.
常见的包含这些缺陷的例子有
"隐藏" 或 "特定"的链接,仅对管理员或特权用户显示, 但是，如果用户知道这些链接存在，所有的用户都可以访问,如： /admin/adduser.php 或 /approveTransfer.do. 这个问题在实现菜单功能的代码里面特别显著。
应用程序往往允许访问“隐藏”的文件，如静态XML或系统产生的报告，相信安全可以通过隐匿来保护这些文件。
实现强制访问控制的代码，已经过期或不足。例如，假设/ approveTransfer.do曾经是提供给所有用户，但由于引入SOX控制后，这个功能只应该提供给被授权的用户。一个补丁程序可能使这个链接不再显示给未经授权的用户，但用户请求该网页时，实际上没有访问控制程序强制执行权限验证
验证用户权限的代码在客户端而不是在服务器上运行，就像对MacWorld2007的攻击一样。价值$1700的“铂金”级用户经由浏览器中的Javascript批准,而不是在服务器上。。
安全检验
目的是检验访问控制对应用程序的所有链接在表现层和业务逻辑层始终得到强制执行
自动方法:弱点扫描和静态分析工具都很难检验URL访问控制, 但是由于不同的原因弱点扫描工具很难猜测隐藏的网页并判定哪些网页可以被所有的用户访问,，静态分析工作尽力识别代码中定制的访问控制并把表现层和业务逻辑性连在一起。
人工检验：最有效率和精确的办法是代码审查和安全测试结合来检验访问控制机制. 如果授权是采用集中管理的方法，检验将非常快速.如果是分布在整个代码中,检验将是非常耗时的. 如果是通过外部强制机制，哪么配置必须被检查和测试 (如认证通过IIS来执行，哪么IIS的配置必须检查和测试)。
保护
花时间通过建立授权矩阵来实现针对URL限制的保护，规划应用程序的角色和功能是关键的步骤，WEB应用程序心须对每个URL以及业务功能进行强制的访问控制.把访问控制放在表现层而使业务逻辑层不在保护之中也是不行的. 在流程中只检查用户是否授权用户一次，而不在后续的步骤中再次检查也是不够的.否则一个攻击者能简单绕过检查步骤然后伪造需要的参数来继续后面的步骤。
可行的URL访问控制得益于仔细的计划，其中重要的事项包括：
* 确认访问控制矩阵是业务、架构、和应用程序设计的一部份
* 确认所有的链接和业务功能通过有效的访问控制机制保护，在任何处理之前先检验用户的角色和权限。确认多步骤流程的每个步骤都进行权限验证，而不仅仅是在第一个步骤。
* 对部署或交付的代码实施一个渗透测试以确认应用程序不会被有动机的经验丰富的攻击者攻击。
* 关注include/library下面的文件，特别是那些有可执行扩展名如：php 的文件.可行的话，它们最好不放在web目录下.需要检验它们是否能被直接访问,如检查一些只能被库的调用者建立的常量。
* 不要假设用户不知道特殊的或隐含的URL或API。总是确认管理员或特权用户的功能受到保护。
* 阻止访问应用程序没有提供的文件类型，完美的方法是遵循“接受已确认的有效的文件类型”并只许访问你打算提供的文件类型。如:.html,.pdf,.php等。这将直接阻止访问日志文件、XML文件及其他你没打算提供的文件的任何企图
* 及时更新杀毒软件和计算机组件补丁如：XML处理程序、文字处理程序、图像处理程序等等, 这些组件处理用户输入的数据。