前端安全:别让你的应用变成黑客的游乐场

前端安全:别让你的应用变成黑客的游乐场

毒舌时刻

这代码写得跟网红滤镜似的——仅供参考。

各位前端同行,咱们今天聊聊前端安全。别告诉我你还在写明文存储密码,那感觉就像把家门钥匙挂在门口——方便,但不安全。

为什么你需要前端安全

最近看到一个项目,登录表单直接把密码发送到服务器,没有任何加密。我就想问:你是在做应用还是在给黑客送大礼?

反面教材

// 反面教材:不安全的登录 // components/LoginForm.jsx export default function LoginForm() { const [username, setUsername] = useState(''); const [password, setPassword] = useState(''); const handleSubmit = async (e) => { e.preventDefault(); // 直接发送明文密码 const response = await fetch('/api/login', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ username, password }) // 明文密码 }); if (response.ok) { // 登录成功 } }; return ( <form onSubmit={handleSubmit}> <input type="text" value={username} onChange={(e) => setUsername(e.target.value)} placeholder="用户名" /> <input type="password" value={password} onChange={(e) => setPassword(e.target.value)} placeholder="密码" /> <button type="submit">登录</button> </form> ); } // 密码在网络传输中是明文 // 本地存储也是明文 

毒舌点评:这代码,密码明文传输,你是在写应用还是在做黑客培训?

前端安全的正确姿势

1. 密码加密

// 正确姿势:密码加密 // utils/auth.js import bcrypt from 'bcryptjs'; export async function hashPassword(password) { const salt = await bcrypt.genSalt(10); return await bcrypt.hash(password, salt); } export async function comparePassword(password, hashedPassword) { return await bcrypt.compare(password, hashedPassword); } // 服务端登录处理 // api/login.js export default async function handler(req, res) { const { username, password } = req.body; const user = await User.findOne({ username }); if (!user) { return res.status(401).json({ error: '用户不存在' }); } const isMatch = await comparePassword(password, user.password); if (!isMatch) { return res.status(401).json({ error: '密码错误' }); } // 生成 JWT token const token = generateToken(user.id); res.json({ token }); } 

2. XSS 防护

// 正确姿势:防止 XSS // components/Comment.jsx import DOMPurify from 'dompurify'; export default function Comment({ content }) { // 净化 HTML 内容 const sanitizedContent = DOMPurify.sanitize(content); return ( <div dangerouslySetInnerHTML={{ __html: sanitizedContent }} /> ); } // 服务器端设置 CSP 头 // next.config.js module.exports = { async headers() { return [ { source: '/(.*)', headers: [ { key: 'Content-Security-Policy', value: "default-src 'self'; script-src 'self' 'unsafe-inline' https://trusted-cdn.com" } ] } ]; } }; 

3. CSRF 防护

// 正确姿势:防止 CSRF // pages/api/protected.js import csrf from 'csurf'; const csrfProtection = csrf({ cookie: true }); export default function handler(req, res) { csrfProtection(req, res, () => { // 受保护的 API 逻辑 }); } // 客户端 // components/Form.jsx export default function Form() { const [csrfToken, setCsrfToken] = useState(''); useEffect(() => { // 获取 CSRF token fetch('/api/csrf-token') .then(res => res.json()) .then(data => setCsrfToken(data.token)); }, []); const handleSubmit = async (e) => { e.preventDefault(); await fetch('/api/protected', { method: 'POST', headers: { 'Content-Type': 'application/json', 'X-CSRF-Token': csrfToken }, body: JSON.stringify({ data: 'test' }) }); }; return ( <form onSubmit={handleSubmit}> <input type="hidden" name="_csrf" value={csrfToken} /> {/* 表单内容 */} </form> ); } 

毒舌点评:这才叫现代前端,安全第一,让黑客无处下手。

Read more

服务端之NestJS接口响应message编写规范详解、写给前后端都舒服的接口、API提示信息标准化

服务端之NestJS接口响应message编写规范详解、写给前后端都舒服的接口、API提示信息标准化

MENU * 前言 * 定义 * 提示信息设计原则 * 提示信息风格分类 * 提示信息模板化设计 * 国际化与多语言支持 * 最佳实践 * 参考示例(NestJS响应) * 总结 * 统一风格示例清单推荐 * API响应message清单(可直接使用) 前言 在现代后端开发中,接口响应不仅仅是数据的传递,还承担着向前端或用户传递操作状态和结果的功能。一个规范、统一的message字段设计,可以显著提升系统的可维护性、前端开发效率和用户体验。 定义 响应结构示例(NestJS风格) 各字段作用 提示信息设计原则 简洁明了 1、不宜过长,一般3~12个汉字。 2、避免含糊不清的词,如“完成了”、“OK”等。 统一风格 1、同一项目接口建议使用统一动词+状态组合,例如:获取数据成功、数据加载完成。 上下文清晰 1、提示信息应体现操作对象或类型,如“用户列表获取成功”

【技术干货】用 Claude 4.6 直接“写”出可上线的前端 UI:从画布工具到代码工作流的升级思路

【技术干货】用 Claude 4.6 直接“写”出可上线的前端 UI:从画布工具到代码工作流的升级思路

摘要 本文从 Google Stitch 热度切入,对比“AI 画布式 UI 生成”与“代码内 UI 生成”两种路径,系统拆解如何用 Claude 4.6 + 前端设计规则,在真实代码库中迭代出可上线的 UI。附完整 Python API 调用示例与提示词模板,并结合多模型平台薛定猫 AI 的接入方式,帮助前端/全栈开发者把 AI UI 生成直接融入开发流水线。 一、背景:从“好看截图”到“可上线 UI” 当前 AI UI 方向大致两类路径: 1. 画布式设计工具 代表:Google Stitch

实验三 Windows Server 2022/2025 搭建 Web 服务器实验指导书

实验三 Windows Server 2022/2025 搭建 Web 服务器实验指导书

作者:非凡大爹|版本:v1|日期:2026-03-30|DocID:CN-LAB-2026-03-WEB-1-LG-V1 原创声明:本文为非凡大爹原创,首发于ZEEKLOG,转载或引用请注明出处。 一、实验基本信息 课程名称: Windows 网络管理 / 网络操作系统 / 服务器配置与管理 实验名称: Windows Server 2022/2025 搭建 Web 服务器 实验性质: 验证性 + 应用性实验 实验类别: 综合配置实验 建议学时: 2 学时 实验方式: 学生独立操作 + 结果验证 二、实验目的 1. 知识目标 理解 Web 服务器的基本作用,了解网站从“本地网页文件”到“网络可访问服务”的基本发布过程,

Go语言中的未来:从泛型到WebAssembly

Go语言中的未来:从泛型到WebAssembly 前言 作为一个在小厂挣扎的Go后端老兵,我对Go语言未来的理解就一句话:能进化的绝不固步自封。 想当年刚接触Go语言时,它还没有泛型,没有模块系统,甚至连错误处理都被人诟病。现在的Go语言已经今非昔比,泛型来了,模块系统完善了,错误处理也有了更多选择。 今天就聊聊Go语言的未来发展,从泛型到WebAssembly,给大家一个能直接抄作业的方案。 为什么需要关注Go语言的未来? 我见过不少小团队,只关注当前的技术,不关心语言的发展趋势,结果技术栈逐渐落后。关注Go语言的未来能带来很多好处: * 提前准备:了解未来的特性,提前调整代码结构 * 技术选型:根据未来趋势,做出更合理的技术选型 * 职业发展:掌握最新技术,提升个人竞争力 * 项目规划:根据语言发展,制定更合理的项目规划 泛型 泛型是Go 1.18引入的重要特性,它能让我们编写更加通用的代码。 基本用法 // 定义泛型函数 func Map[T, U any](s []T, f