在Web开发框架中，拦截器（Interceptor）和AOP（面向切面编程）的执行顺序如果配置不当，会直接导致权限校验被绕过，攻击者可以在未经过认证的情况下访问受保护的资源。这个问题的核心在于：当AOP切面先于拦截器执行时，拦截器中的权限检查逻辑可能被跳过；或者当多个拦截器/切面之间的优先级设置错误时，后执行的校验会覆盖先执行的校验结果。解决这个问题的关键是明确执行链路、统一优先级管理、以及在框架层面做防御性编程。下面我会从原理、场景、漏洞复现、修复方案四个维度把这个问题讲透。

一、拦截器与AOP的执行机制到底是怎么回事

先把基础概念说清楚。拦截器是框架层面的请求过滤机制，比如Spring MVC的HandlerInterceptor、Struts2的Interceptor，它们在请求到达Controller之前或之后执行。AOP则是通过动态代理或字节码增强，在方法调用前后插入额外逻辑，比如Spring AOP的@Aspect注解。两者本质上都是"在目标逻辑执行前后插入代码"，但它们的触发时机和执行顺序由框架的调度器决定。

问题就出在这里。大多数框架的执行链是这样的：请求进入 → 过滤器（Filter） → 拦截器（Interceptor） → AOP切面 → Controller方法。但这个顺序不是绝对的。在Spring MVC中，如果你用了@Aspect定义的切面，同时又配置了HandlerInterceptor，它们的执行顺序取决于注册方式和优先级配置。如果AOP切面的优先级高于拦截器，那么切面中的逻辑会先执行，而拦截器中的权限校验就可能被"架空"。

二、权限绕过是怎么发生的——三种典型场景

场景一：AOP切面先于拦截器执行，导致校验失效

假设你在Controller方法上用AOP做了日志记录，同时在拦截器中做了权限校验。如果AOP切面的order值比拦截器小（优先级更高），那么请求会先经过AOP，再经过拦截器。这时候如果拦截器的逻辑是"检查token，通过则放行"，而AOP切面在方法执行后又做了某些操作，可能会导致请求在拦截器校验之前就已经触发了某些内部调用，绕过了第一道防线。更危险的情况是，某些框架在AOP执行后会直接调用目标方法，而拦截器的preHandle根本没被触发到。

场景二：多个拦截器之间顺序错误，后置校验覆盖前置结果

很多项目会配置多个拦截器，比如一个做日志、一个做权限、一个做跨域处理。如果权限拦截器的order值比日志拦截器大（后执行），而日志拦截器中有某种逻辑会修改请求属性或session状态，那么权限拦截器拿到的可能是被篡改后的数据，校验结果自然不可靠。反过来，如果权限拦截器先执行并放行了，后面的拦截器又做了一次"宽松"的校验，等于双重失效。

场景三：AOP切面内部调用自身方法，绕过代理

这是最隐蔽的一种。在Spring AOP中，如果同一个类内部方法A调用方法B，而方法B上有切面注解，那么这个调用不会经过代理，切面逻辑不会执行。如果你的权限校验是通过AOP切面实现的，而Controller内部有自调用逻辑，那么这部分调用完全不会被校验到，形成天然的绕过通道。

三、用代码复现这个漏洞

下面用Spring Boot + Spring MVC的例子来演示。假设我们有一个权限拦截器和一个AOP切面：

@Component
public class AuthInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String token = request.getHeader("Authorization");
        if (token == null || !token.startsWith("Bearer ")) {
            response.setStatus(401);
            return false;
        }
        return true;
    }
}

@Aspect
@Component
@Order(1)  // 优先级最高，先于拦截器执行
public class LogAspect {
    @Around("execution(* com.example.controller.*.*(..))")
    public Object around(ProceedingJoinPoint point) throws Throwable {
        System.out.println("Log: " + point.getSignature().getName());
        return point.proceed();  // 直接放行，不做任何校验
    }
}

在这个例子中，LogAspect的@Order(1)让它比拦截器先执行。虽然拦截器本身有校验逻辑，但如果框架的调度机制让AOP的@Around在拦截器的preHandle之前就触发了point.proceed()，那么请求实际上是绕过了拦截器的。更实际的漏洞是：如果你把权限校验也放在AOP里，但order设错了，校验就会在错误的时机执行。

四、系统性修复方案——五步搞定

第一步：统一优先级管理，权限校验必须最先执行

不管你用拦截器还是AOP做权限校验，都要确保它是整个执行链中最先被触发的。在Spring中，拦截器通过registry.addInterceptor().order()设置顺序，AOP通过@Order注解。建议把权限相关的逻辑全部放在拦截器的preHandle中，并且order设为最小值（比如Integer.MIN_VALUE）。AOP只用来做日志、监控等非安全相关的切面。

@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new AuthInterceptor())
                .order(Integer.MIN_VALUE)  // 最先执行
                .addPathPatterns("/")
                .excludePathPatterns("/login", "/register");
    }
}

第二步：禁止在AOP中做核心权限校验

AOP适合做横切关注点，比如性能监控、异常处理、事务管理。但权限校验是纵切关注点，它和业务逻辑强耦合，放在AOP里容易出顺序问题。最佳实践是：权限校验放在拦截器或Filter层，AOP只做辅助。如果你一定要用AOP做权限，必须确保切面的执行顺序在所有拦截器之前，并且要处理自调用问题。

第三步：解决AOP自调用绕过问题

Spring AOP基于代理，同类内部调用不会触发代理。解决方案有三个：一是把需要校验的方法拆到另一个Service类中；二是使用AspectJ编译时 weaving 或 load-time weaving，它能处理自调用；三是在方法内部手动获取代理对象。推荐第一种，最简单也最不容易出错。

// 错误写法：自调用，切面不生效
@Service
public class UserService {
    public void createUser(User user) {
        validatePermission();  // 不会触发AOP
    }
    @PreAuthorize("hasRole('ADMIN')")
    public void validatePermission() { ... }
}

// 正确写法：拆分到不同类
@Service
public class UserService {
    @Autowired
    private PermissionService permissionService;
    public void createUser(User user) {
        permissionService.validatePermission();  // 触发AOP
    }
}

第四步：在框架层面加防御性校验，不依赖单一机制

永远不要只靠一层校验。建议在Filter层做第一次token解析，在拦截器层做第二次权限判断，在Controller方法上再加注解式校验（比如@PreAuthorize）。三层校验即使有一层因为顺序问题失效，另外两层还能兜底。这叫"纵深防御"，是安全架构的基本原则。

第五步：写自动化测试验证执行顺序

很多团队忽略了这一步。你应该写集成测试，模拟无token请求，验证在各种配置组合下是否都能被拦截。可以用Spring的MockMvc配合自定义的Filter/Interceptor来测试执行链。如果测试发现某个路径能绕过校验，说明顺序配置有问题，必须马上修。

五、进阶：不同框架的特殊注意点

如果你用的是Struts2，它的拦截器栈（Interceptor Stack）本身就有严格的顺序，defaultStack中权限相关的拦截器通常在前面。但如果你自定义了拦截器并插入到栈中间，就可能破坏原有顺序。Struts2的解决方案是明确指定interceptor-ref的位置，或者创建新的栈并在struts.xml中配置。

如果你用的是Spring Security，它本身就是基于Filter链的，顺序由FilterChainProxy管理。Spring Security的Filter通常要放在最前面，确保在任何业务逻辑之前就完成认证。如果你在它后面又加了自定义Filter做权限，要注意Filter的order配置。

对于Node.js的Express框架或者Python的Django中间件，原理类似。中间件的执行顺序就是注册顺序，权限中间件必须注册在路由处理之前。任何放在后面的中间件都无法阻止前面已经放行的请求。

六、总结与建议

拦截器和AOP的顺序问题不是小问题，它直接关系到系统的安全底线。核心原则就三条：第一，权限校验放在最前面，不管是Filter、拦截器还是AOP，优先级必须最高；第二，不要把核心安全逻辑放在容易出顺序问题的机制里，AOP适合做非安全切面；第三，多层校验、纵深防御，永远不要信任单一的安全机制。把这三条落实到代码规范和Code Review流程中，这类漏洞基本可以杜绝。

最后提醒一点，这个问题在实际项目中非常常见，尤其是在团队协作、多人维护的大型项目中，不同开发者各自加拦截器或切面，很容易忽略顺序冲突。建议团队建立统一的拦截器/切面注册规范，用文档或配置中心明确每个组件的执行优先级，从制度上防止这类问题。