在现实世界中，为什么我们需要实现方法级安全性？
我们有一个Web应用程序或一个桌面应用程序，用户可以在其中访问用户界面（因此无法直接访问该方法）。
那么，这里的访问方法直接体现在哪里呢？
编辑：我问这个问题，因为我正在尝试使用spring安全性，并且看到授权用户访问方法。
就像是 ：
@ROLE_ADMIN
public void update() {
//update
}
Answers:
在正确设计的应用程序中，后端和前端是断开的。后端安全系统不能假定任何特定的前端将正确处理安全性，因此它必须自己处理。
我假设您正在谈论基于角色对控制器中操作的访问。即在MVC体系结构中，Controller类上的每个方法都是单独的操作。我使用的大多数MVC框架都允许我在方法级别和类级别分配权限。这意味着我可以在类级别应用属性/注释，并且该控制器中的每个动作都需要相应的角色。
关于基于角色的访问的更细粒度的控制，请考虑以下事项：
不管您喜不喜欢，几年前Ruby on Rails流行时，几乎每个MVC框架都复制了其基本设计方法。过去，动作是单独的类，但是动作逻辑往往较小且集中，因此整个类的开销过大。将控制器上的方法映射到页面的动作实际上很有意义。只是知道很多人需要对哪些角色可以执行哪些功能进行细粒度的控制。
方法级别的安全性之所以有用，主要有两个原因：
作为另一安全层（除了其他层）
如果在方法级别拥有权限更为方便或合乎逻辑，请考虑以下情况：不同的用户可以执行相同的“直接”操作（因此客户端安全性无关）。但在某些情况下，其操作可能会触发您希望限制的行为-在这种情况下，方法级别的安全性可能是一个相关的解决方案。
Mike Wiesner在此SpringSource演示中提醒： “ Spring Security 3 / 3.1简介”中回了一个示例，即Tomcat和许多其他Servlets容器存在一个错误，当以unicode编码时，该错误无法正确识别“ ../”。一个简单的equals测试在Java中将失败，但会转换为文件系统中的上层目录。
安全是很难的，多重安全级别将提高阻止规避尝试的机会。由于方法级别的安全性是直接在类内部编码的，因此在AOP扩充之后，调用该方法时，您总是会在此之前调用安全性检查。
我假设您在这里谈论的是公共，私有和受保护的方法？
如果是这样，那么出于安全目的它们就不存在。存在它们的目的是为了更轻松地保证软件正确地模块化。（他们是否成功在那是一场辩论，我将留给其他人讨论。但是，这就是他们的目的的愿景。）
假设我提供了一个库，那么以后我可以自由地提供一个不同版本的库，并根据需要更改标记为私有的内容。相比之下，如果我没有将这些内容标记为私有，那么我将无法更改软件的任何内部结构，因为某个地方的某个人可能正在直接访问它。当然，从理论上讲，不使用记录在案的API是他们的错。但是客户会认为我的错误是我的软件升级破坏了他们的软件。他们不想找借口，他们想解决这个问题。但是，如果我不让他们具有访问权限的开始，那么我的API正是我打算成为我的API的公共方法，并且避免了该问题。
您可能要谈论的第二个最可能的事情是Java的安全模型。如果您在谈论这一点，那么它存在的原因是Java的最初愿景涉及人们发送可能不受信任的小程序，以便它们在第三方程序（例如浏览器）中进行交互工作。因此，该安全模型旨在为用户提供一些防范恶意小程序的保护。因此，担心和防范的安全威胁是试图与可能已加载的其他软件进行交互的不受信任的applet。