本文介绍在无法修改 apache 配置（如禁用 .htaccess）时，通过 php 应用层逻辑实现“仅允许特定页面（如 a.php/b.php/c.php）调用 compute.php，禁止浏览器直接访问”的实用方案，并说明其原理、局限性与增强措施。
本文介绍在无法修改 apache 配置（如禁用 .htaccess）时，通过 php 应用层逻辑实现“仅允许特定页面（如 a.php/b.php/c.php）调用 compute.php，禁止浏览器直接访问”的实用方案，并说明其原理、局限性与增强措施。
在 Web 开发中，常需将业务逻辑封装为独立 PHP 脚本（如 compute.php），供前端页面通过 AJAX 异步调用，但又不希望该脚本被用户在浏览器中直接请求（如 http://localhost/compute.php?number=800）。当无法使用 .htaccess 或服务器主配置进行访问控制时，必须转向应用层防护策略——需明确一点：HTTP 协议本身无法可靠区分 AJAX 请求与手动浏览器访问，因为两者最终都发出标准 HTTP 请求，服务端无法仅凭请求方式（GET/POST）、来源路径或 JS 上下文做绝对判定。因此，所有纯客户端侧的“伪装”（如检查 X-Requested-With: XMLHttpRequest）均不可信，易被绕过。
✅ 可行且推荐的实践方案是：结合请求来源验证 + 通信凭证 + 方法约束，构建多层防御：
1. 强制使用 POST + 秘钥校验（基础可靠方案）
在 a.php、b.php、c.php 的 AJAX 调用中改用 POST，并附带预共享密钥（secret token）：
// a.php 中的调用示例
$.post("compute.php", {
number: 800,
token: "a1b2c3d4e5" // 预设密钥，建议从 session 或配置文件读取，勿硬编码
});在 compute.php 开头添加严格校验逻辑：
立即学习“PHP免费学习笔记（深入）”；
<?php
// compute.php —— 服务端入口防护
$expected_token = 'a1b2c3d4e5'; // 生产环境应从 config.php 或 $_SESSION 动态获取
$allowed_ips = ['127.0.0.1', '::1']; // 可选：限制仅本地请求（适用于开发/内网）
// 检查是否为 POST 请求
if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
http_response_code(405);
die('Method Not Allowed');
}
// 校验 token
if (!isset($_POST['token']) || $_POST['token'] !== $expected_token) {
http_response_code(403);
die('Access Denied');
}
// （可选）校验请求来源 IP
if (!in_array($_SERVER['REMOTE_ADDR'], $allowed_ips, true)) {
http_response_code(403);
die('Forbidden: Direct access not permitted');
}
// ✅ 安全校验通过，执行业务逻辑
$number = (int)($_POST['number'] ?? 0);
$result = $number * 2; // 示例计算
echo json_encode(['success' => true, 'result' => $result]);⚠️ 注意：token 不应写死在前端 JS 中（易被审查源码获取）。更安全的做法是：
Accessibility Review下载对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
- 在 a.php 等页面加载时，由 PHP 生成一次性 token 并注入到 JS 变量或 data 属性；
- 或使用 session 存储 token，AJAX 请求前先通过 /api/get-token.php 获取（需配合 CSRF 保护）。
2. 基于 Referer 的辅助校验（低强度补充，不可单独依赖）
虽然 HTTP_REFERER 可被伪造，但在内网或可控环境中可作为轻量级辅助判断：
$valid_referers = [
'http://localhost/a.php',
'http://localhost/b.php',
'http://localhost/c.php'
];
$referer = $_SERVER['HTTP_REFERER'] ?? '';
if (!in_array($referer, $valid_referers, true)) {
http_response_code(403);
die('Invalid referer');
}? 提示：此方式仅适合非高敏场景，绝不可替代 token 或身份认证。
3. 进阶加固：分离 Web 入口与逻辑层（推荐架构）
从根本上规避风险的最佳实践是物理隔离：将 compute.php 移出 Web 可访问目录（DocumentRoot），仅保留 index.php 或 API 入口在 Web 根下，通过 require_once 包含逻辑文件：
/var/www/
├── public/ ← DocumentRoot（Apache/Nginx 指向此处）
│ ├── a.php
│ ├── b.php
│ ├── c.php
│ └── api/ ← 统一 API 入口
│ └── compute.php ← 此文件实际是路由转发器
└── app/
└── logic/
└── compute_handler.php ← 真正的业务逻辑，Web 不可直接访问public/api/compute.php 内容示例：
<?php // public/api/compute.php —— 受控入口 require_once __DIR__ . '/../../app/logic/compute_handler.php'; handleComputeRequest(); // 封装好的函数，含完整校验
此时即使攻击者尝试访问 http://localhost/app/logic/compute_handler.php，也会因路径不在 Web 根下而返回 404（前提是服务器未错误配置别名或符号链接）。
总结
- ❌ 不存在能 100% 可靠区分“AJAX 调用”与“浏览器直接访问”的 HTTP 层机制；
- ✅ 有效方案 = POST + 密钥校验 + 请求方法/参数白名单 +（可选）IP/Referer 辅助判断；
- ✅ 最佳架构 = 将核心逻辑文件移出 Web 根目录，仅暴露受控 API 入口；
- ? 切勿依赖 $_SERVER['HTTP_X_REQUESTED_WITH'] 或简单 Referer 做唯一防线；
- ? 生产环境务必启用 display_errors = Off，并记录异常访问日志以便审计。
通过以上组合策略，可在不依赖 .htaccess 的前提下，显著提升 compute.php 类脚本的安全水位，兼顾功能性与防护性。
