PHP微服务无内置安全架构，须显式实现JWT校验（含exp/nbf/iss/roles）、gRPC双向TLS认证、Phalcon ACL三元组授权、容器非root运行及端到端链路防护。
PHP微服务本身不自带安全架构，所有安全能力必须显式设计并落地——没配置的JWT是裸奔，没校验的gRPC请求等于开门揖盗，ACL规则漏写一条就可能越权访问。
JWT签名验证必须手动校验，jwt_decode() 不等于鉴权完成
很多开发者误以为调用 firebase/php-jwt 的 JWT::decode() 就完成了认证，其实它只做解析和签名验证，不检查 exp、nbf、iss 或角色声明。生产环境必须补全校验逻辑：
-
exp和nbf字段需用time()显式比对，不能依赖库的自动忽略行为 -
iss（issuer）必须白名单校验，防止其他域签发的 token 冒充本系统服务 - payload 中的
scope或roles需提取后传入 ACL 检查，不能仅凭解码成功就放行 - 密钥必须从 Vault 或 Kubernetes Secrets 加载，禁止硬编码或读取
.env
gRPC通信必须启用TLS双向认证，ssl_target_name_override 不能关
PHP 使用 mix/grpc 或 grpc/grpc 扩展时，若未启用 TLS，所有 service-to-service 调用都在明文传输。即使内部网络，也应强制 mTLS：
- 服务端必须配置
ssl_certificate和ssl_private_key，客户端必须提供ssl_ca_cert - 客户端初始化 Channel 时，
ssl_target_name_override必须设为服务端证书中 CN 或 SAN 域名，不可设为"localhost"或留空 - 禁用
grpc.ssl_target_name_override等同于关闭证书域名校验，中间人可伪造任意服务响应 - 建议用
phpseclib的X509类在启动时校验证书有效期与吊销状态（OCSP）
Phalcon ACL规则必须按“资源→操作→角色”三元组注册，addInherit() 易导致权限蔓延
Phalcon 的 AclMemory 默认不继承规则，但开发者常误用 addInherit('admin', 'user') 让 admin 继承 user 权限，结果反而让低权限角色获得高权限操作路径：
立即学习“PHP免费学习笔记（深入）”；
- 正确做法是显式添加：
$acl->allow('admin', 'orders', ['create', 'read', 'update']) - 避免
addInherit()，改用角色聚合（如定义role: power_user并单独赋予权限） - 资源名必须与控制器/动作严格对齐，例如
$acl->addResourceName('users', 'UsersController')后，检查时必须用$acl->isAllowed('admin', 'users', 'read')，错写成'UserController'就失效 - 每次请求前需调用
$acl->rebuild()（若规则动态加载），否则内存缓存可能 stale
容器内PHP进程必须降权运行，www-data 不等于安全
Docker 默认以 root 启动 PHP-FPM 或 Swoole 进程，即使用户改为 www-data，只要没限制 capabilities 和文件系统挂载，攻击者仍可逃逸或提权：
- Dockerfile 中必须加
USER 1001:1001（非 root UID/GID），并确保/var/www目录属主同步变更 - 启动命令前加
setcap 'cap_net_bind_service=+ep' /usr/local/bin/php（如需绑定 80 端口），而非用root启动再降权 - 禁止挂载宿主机
/proc、/sys或敏感目录，--read-only标志应默认开启 - Alpine 镜像中禁用 shell：用
apk del bash清理交互入口，防止反向 shell
最常被跳过的环节是服务间调用链路的端到端完整性校验——API网关验了JWT，gRPC服务端验了mTLS，但下游MySQL连接没开 PDO::ATTR_EMULATE_PREPARES = false，一条恶意输入仍能绕过所有前置防护直击数据库。
