PHP全局变量本身不危险，但直接未经校验使用会导致XSS、SQL注入、变量覆盖、路径遍历等安全风险，必须对所有用户输入进行类型校验、输出转义、参数化查询和白名单控制。
PHP 全局变量（如 $_GET、$_POST、$_COOKIE、$_SERVER、$GLOBALS 等）本身不是“危险”的，但直接、未经校验地使用它们，是 PHP 安全漏洞的常见源头。面试中问这个问题，核心是考察你对输入信任、作用域控制和安全编码意识的理解。
直接输出全局变量内容 → XSS 风险
把 $_GET['name'] 或 $_POST['comment'] 未经转义就 echo 到 HTML 页面，攻击者可注入恶意脚本。
- 错误示例：
echo $_GET['q'];（用户传入q=<script>alert(1)</script>就会执行） - 正确做法：输出前用
htmlspecialchars()转义：echo htmlspecialchars($_GET['q'] ?? '', ENT_QUOTES, 'UTF-8'); - 注意：
htmlentities()或 Twig/Vue 等模板引擎的自动转义也可用，但不能依赖前端 JS 过滤——服务端必须做
未验证就用于数据库查询 → SQL 注入
拼接 SQL 字符串时直接嵌入 $_POST['id'] 或 $_GET['sort']，极易被构造恶意语句绕过逻辑或拖库。
- 错误示例：
$sql = "SELECT * FROM users WHERE id = " . $_GET['id']; - 正确做法：强制类型转换 + 参数化查询：
$id = (int)$_GET['id']; $stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?"); $stmt->execute([$id]); - 特别注意：
$_GET['sort']这类字段不能简单 cast int，应限定白名单：$allowed = ['name', 'created_at']; $sort = in_array($_GET['sort'] ?? '', $allowed) ? $_GET['sort'] : 'id';
滥用 $GLOBALS 或 extract() → 变量覆盖与逻辑失控
$GLOBALS 暴露所有全局作用域变量；extract($_POST) 会把请求参数直接变成局部变量，可能意外覆盖关键变量（如 $user、$is_admin）。
立即学习“PHP免费学习笔记（深入）”；
- 风险示例：
extract($_REQUEST); if ($is_admin) { deleteAllUsers(); }—— 攻击者加?is_admin=1即可提权 - 避免方案：禁用
extract()；不用$GLOBALS读写业务数据；敏感状态（如登录态）必须从 Session 或 Token 中明确获取并校验 - 开发环境关闭
register_globals（PHP 5.4+ 已移除，但遗留代码或配置需确认）
信任 $_SERVER 中的值 → 请求伪造与路径遍历
$_SERVER['HTTP_REFERER']、$_SERVER['HTTP_USER_AGENT']、$_SERVER['PATH_INFO'] 等均可被客户端任意修改，不能用于权限判断或文件操作。
- 典型错误：
if (strpos($_SERVER['HTTP_REFERER'], 'admin.example.com') !== false) { allowAccess(); }—— Referer 极易伪造 - 更危险：
include $_SERVER['PATH_INFO'] . '.php';→ 攻击者传/../../etc/passwd%00可读取任意文件 - 安全建议：权限校验走后端 Session/Token；文件路径用白名单或映射表；
PATH_INFO需正则严格匹配（如/^[a-z0-9_]+$/）
不复杂但容易忽略：全局变量是入口，不是数据源。任何来自用户的输入，无论它藏在哪个超全局数组里，都必须当作不可信数据处理——校验类型、过滤内容、转义输出、参数化查询、最小权限访问。
