PHP MVC中间件管道中拒绝文本POST端点multipart请求的最优方案

问题背景 #

针对PHP 7.4+的MVC博客应用进行纵深防御加固时，安全扫描发现所有纯文本POST端点（登录、搜索、评论提交等）都会静默接受multipart/form-data类型请求。尽管这些端点没有文件上传逻辑，但需要提前拒绝此类请求以缩小攻击面，仅允许唯一的上传端点POST /admin/posts/upload-image接收该类型请求。

核心需求 #

• 非上传POST端点收到multipart/form-data请求时，返回HTTP 415 Unsupported Media Type
• 保留对application/x-www-form-urlencoded（普通表单）和application/json（AJAX端点）类型POST请求的支持
• 全面覆盖所有POST端点，无遗漏

最优实现方案：全局中间件+白名单校验 #

1. 编写ContentTypeValidationMiddleware #

利用现有洋葱式中间件管道，新增专门的内容类型校验中间件，在请求到达控制器前完成校验：

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;

final class ContentTypeValidationMiddleware implements MiddlewareInterface
{
    // 仅允许接收multipart的端点白名单
    private const ALLOWED_MULTIPART_ROUTES = [
        '/admin/posts/upload-image'
    ];

    // 允许的POST请求Content-Type集合
    private const ALLOWED_POST_CONTENT_TYPES = [
        'application/x-www-form-urlencoded',
        'application/json',
        'multipart/form-data'
    ];

    public function handle(callable $next)
    {
        $request = Request::createFromGlobals();

        // 仅处理POST请求
        if ($request->getMethod() !== Request::METHOD_POST) {
            return $next();
        }

        $contentType = $request->headers->get('Content-Type');
        if (empty($contentType)) {
            return $next();
        }

        // 提取主Content-Type（忽略charset等附加参数）
        $mainContentType = explode(';', $contentType)[0];

        // 校验multipart类型请求
        if ($mainContentType === 'multipart/form-data') {
            $currentUri = $request->getPathInfo();
            if (!in_array($currentUri, self::ALLOWED_MULTIPART_ROUTES)) {
                return new Response('Unsupported Media Type', Response::HTTP_UNSUPPORTED_MEDIA_TYPE);
            }
        } 
        // 校验其他POST类型请求
        else {
            if (!in_array($mainContentType, self::ALLOWED_POST_CONTENT_TYPES)) {
                return new Response('Unsupported Media Type', Response::HTTP_UNSUPPORTED_MEDIA_TYPE);
            }
        }

        return $next();
    }
}

2. 加入中间件管道 #

将新增的中间件插入到管道靠前位置（确保所有POST请求都能被提前校验）：

$pipeline = (new MiddlewarePipeline())
    ->add(new SessionMiddleware())
    ->add(new ContentTypeValidationMiddleware()) // 新增校验中间件
    ->add(new SecurityHeadersMiddleware())
    ->add(new CorsMiddleware())
    ->add(new ApiAuthMiddleware())
    ->add(new PostAccessMiddleware());

方案优势 #

1. 全面覆盖：中间件作用于所有请求，无需担心遗漏使用原生$_SERVER['REQUEST_METHOD']校验的控制器端点
2. 低维护成本：仅需维护一个单元素的白名单，后续新增上传端点只需追加数组元素
3. 关注点分离：安全校验逻辑独立封装在中间件中，不污染控制器或Dispatcher的核心职责
4. 兼容性强：完美适配现有普通表单和AJAX JSON请求的需求

其他方案的不足 #

• 方案B（修改基础控制器）：需重构30+使用原生POST校验的控制器，工作量大且易遗漏，无法覆盖路由绑定闭包的特殊场景
• 方案C（修改Dispatcher）：混淆了路由分发与安全校验的职责，增加代码耦合度，不利于后续迭代维护

优化扩展（可选） #

若后续路由URI可能变动，可修改中间件逻辑，通过匹配路由对应的控制器和方法而非硬编码URI：

// 假设路由系统支持获取匹配到的控制器和方法
[$controller, $method] = $this->getMatchedRouteInfo($request);

if ($controller !== PostController::class || $method !== 'uploadImage') {
    if ($mainContentType === 'multipart/form-data') {
        return new Response('Unsupported Media Type', Response::HTTP_UNSUPPORTED_MEDIA_TYPE);
    }
}

内容的提问来源于stack exchange，提问作者M Noermoehammad