短链接被还原的关键在于ID与短码的可预测映射关系。主流方案用自增ID+base64编码，易被反推；真正防还原需切断该映射，推荐HashID、AES加密或随机Token查表三种方案。
短链接为什么会被还原？关键在 base64_decode 和整数 ID 暴露
短链接服务（如 https://t.co/abc123）本质是把长 URL 映射到一个短 token，而绝大多数开源实现用的是「ID 自增 + base64 编码」——比如数据库里第 123456 条记录，转成 1eQ0。攻击者只要拿到几个连续短码（aBc2、aBc3、aBc4），就能反推编码逻辑，甚至暴力遍历全部 ID。这不是理论风险，真实发生过批量爬取后台文章、用户私密相册的案例。
核心问题不在「短」，而在「可预测」。所以升级重点不是换更长的字符串，而是切断 ID 与短码之间的可逆映射关系。
PHP 中真正防还原的 3 种加密/混淆方案对比
别再用 base64_encode($id) 或 dechex($id) 了。下面三种才是生产可用的：
-
方案一：HashID（推荐） —— 使用
hashids/hashids库，把数字 ID 加盐后双向混淆，不暴露顺序、不重复、可定制长度和字符集。use Hashids\Hashids; $hashids = new Hashids('my-salt-key-2024', 6, 'abcdefghijklmnopqrstuvwxyz123456789'); $short = $hashids->encode(123456); // 例如得到 'k3m9xv' $id = $hashids->decode($short)[0] ?? null; // 安全还原注意：decode()返回数组，必须检查是否为空；盐值'my-salt-key-2024'必须保密且不可硬编码在前端 JS 里。 -
方案二：AES 加密 + base64（适合敏感场景） —— 把 ID 当作明文，用 AES-128-CBC 加密后再 base64，彻底阻断推测。但要注意：必须固定 IV（或随密文存储），且解密失败时返回 404 而非报错，避免侧信道泄露有效短码范围。
$key = '32-byte-secret-key-must-be-exact'; $iv = str_repeat("\0", 16); $ciphertext = openssl_encrypt($id, 'AES-128-CBC', $key, 0, $iv); $short = rtrim(strtr(base64_encode($ciphertext), '+/', '-_'), '='); // 解密时需 reverse strtr & base64_decode，再 openssl_decrypt -
方案三：随机 Token + 数据库查表（最简单可靠） —— 放弃 ID 编码，直接为每条长链接生成 6～8 位唯一随机字符串（如
bin2hex(random_bytes(4))），存入带UNIQUE约束的short_code字段。查询走索引，性能无压力，且完全不可预测。
常见踩坑：URL 重定向中容易暴露原始 ID 的 3 个位置
即使用了 HashID，以下地方仍可能让攻击者绕过保护：
立即学习“PHP免费学习笔记（深入）”；
-
HTTP Referer 或日志里泄露原始 ID：比如跳转前页面 URL 是
/view?id=123456，即使跳转后地址是/s/k3m9xv，Referer 头或 Nginx access_log 仍含明文 ID。解决方案：所有内部跳转统一走短链，前端禁止拼接含 ID 的 URL。 -
API 接口返回明文 ID：比如
GET /api/shorten响应里同时返回{"short": "k3m9xv", "original_id": 123456}。必须删掉original_id字段，只保留业务所需字段（如created_at）。 -
错误响应暴露存在性：访问
/s/invalid-code返回 404，但访问/s/k3m9xv返回 302，攻击者靠状态码差异就能判断哪些短码“存在”。应统一返回 302（跳转到默认页）或 404，且响应体/头保持一致（比如都禁用X-Powered-By）。
额外建议：别只盯算法，架构层也要设防
单靠 PHP 加密函数无法解决所有问题。真实攻击常结合时间差、频率、行为模式：
- 对
/s/{code}接口加限流：同一 IP 每分钟最多 10 次请求，超限返回 429； - 短码生成后立即写入缓存（Redis），TTL 设为 7 天，避免高频查库；
- 敏感链接（如含
token=或user_id=的 URL）禁止缩短，或强制走方案二（AES）； - 定期审计日志，搜索
GET /s/[a-z0-9]{4,6} HTTP的高频 pattern，及时封禁异常 UA/IP。
最难防的不是技术漏洞，而是开发时觉得“就一个短链，没必要太严”，结果测试环境用的盐值直接提交到 GitHub，或者把加密密钥写在 config.php 里还给了 755 权限。
