java中jdbc最常见安全隐患是凭据泄露和sql注入；须杜绝硬编码密码、强制使用preparedstatement参数化查询、限制数据库账号权限，并通过连接池与try-with-resources规范资源管理。
Java 中 JDBC 访问数据库最常见的安全隐患集中在凭据泄露和SQL 注入两大类，二者都可能直接导致数据被窃取、篡改甚至服务器失陷。防范关键不是“加一层加密”，而是从设计源头切断攻击路径。
杜绝硬编码数据库账号密码
把用户名、密码写死在代码里（如 DriverManager.getConnection(url, "root", "123456")）是高危操作——JAR 包一旦被反编译，凭据即刻暴露。任何客户端侧的“加密”（Base64、AES 等）都不安全，因为解密逻辑和密钥必然随程序分发。
- 推荐做法：由用户运行时输入（如命令行提示或登录界面），连接前才传入凭证
- 次选方案：使用外部配置文件（如
config.properties），但必须确保该文件不提交到 Git，且部署时设置严格文件权限（Linux 下建议chmod 600） - 生产环境更优解：通过操作系统环境变量传入（
System.getenv("DB_PASSWORD")），避免配置文件残留风险
必须用 PreparedStatement 防 SQL 注入
用字符串拼接构造 SQL（如 "SELECT * FROM users WHERE name = '" + name + "'"）等于给攻击者留后门。一个 ' OR '1'='1 就能绕过登录验证。
- 所有含用户输入的查询、更新、删除操作，一律使用
PreparedStatement - 参数占位符
?由 JDBC 驱动自动转义，输入内容永远作为“数据”而非“SQL 代码”执行 - 不要依赖前端校验或简单过滤（如删掉单引号）——这些在服务端都可被绕过
限制数据库账号权限与网络暴露面
即使凭据没泄露、SQL 也没注入，一个高权限账号仍会让攻击后果升级；而错误的连接地址或监听配置，又会让应用根本连不上库。
- 创建专用数据库用户，只授予业务必需的权限（如仅
SELECT, INSERT ON app_db.users），禁用DROP、CREATE USER等管理权限 - JDBC URL 中避免用
localhost——它只指向本机；远程访问需明确填写服务器真实 IP，并确认 MySQL 配置了bind-address = 0.0.0.0或对应 IP - 防火墙必须放行 MySQL 端口（默认 3306），同时禁止公网直接暴露该端口，优先走内网或代理层
规范资源管理，防止连接泄漏
忘记关闭 Connection、Statement、ResultSet 会导致连接池耗尽、数据库响应变慢甚至拒绝服务。
- 使用 try-with-resources 语法，确保资源在作用域结束时自动关闭
- 避免在 finally 块中手动 close —— 若多个 close 抛异常，后者会被前者掩盖
- 连接应来自连接池（如 HikariCP），而非每次 new Connection；池负责复用、超时、健康检查
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
