很多刚接触网络安全的人，都有一个共同的误区：以为搞安全就是拿上扫描器一顿乱扫，或者背几个漏洞编号就完事了。真到实战场景里，前端请求怎么发的、后端响应怎么解析的、浏览器中间动了什么手脚，这些问题一问三不知，连问题都定位不了，更别提挖掘漏洞。第二章第一节课，我把它定位成“把前端基础吃透”，不是教你怎么写页面，而是从安全视角重新理解浏览器、HTML、JavaScript 和 HTTP 这些东西。
这一节的内容，本质上是在搭一个认知框架。你后面学的 SQL 注入、文件上传、逻辑越权，全都要落到具体的请求和响应上，而前端就是这一切的起点。所以这篇文章我会尽量讲透核心原理，带着你从浏览器的视角去看一个网站到底是怎么工作的，再告诉你哪些细节是后续攻防中真正用得上的。如果你能把这部分基础打牢，后面学什么都快。
1. 先搞清楚Web安全到底在学什么
1.1 Web安全的全景地图
Web安全不是一个孤立的技术点，它覆盖的范围非常广。粗略划分一下，至少包括这么几层：客户端（浏览器）、传输链路（HTTP/HTTPS）、服务端（Web服务器与业务逻辑）、数据存储（数据库）以及运维部署（服务器环境、容器、云平台）。
很多新手不知道从哪里下手，就是因为这个领域太宽了。实际上，正常的Web攻击路径一般是这样的：攻击者通过浏览器访问目标站点，浏览器向服务器发起HTTP请求，服务器处理请求并返回响应，浏览器再渲染响应内容。攻击者想要做的就是在这个过程中，想办法让服务器或者浏览器执行一些非预期的事情。
从这个链路去看，前端安全的基础知识就显得非常关键了。你连浏览器端如何解析HTML、JavaScript的执行环境、同源策略的限制机制都不知道，后面的漏洞分析大概率是空中楼阁。
所以第二章-1的内容，就是要把这条链路的最前端——浏览器和前端技术——讲清楚。这一节不直接教你攻击手段，而是给你一张地图，让你知道自己站在哪里。后面的章节会围绕这张地图逐个击破。
1.2 前端安全在攻防中的角色
前端在安全攻防中的角色，比很多人想象中重要得多。先说防御侧：现在很多安全措施是在前端实现的，比如输入校验、参数加密、验证码、风控埋点。虽然前端校验不能作为唯一防线，但它确实是第一道过滤网。理解了前端，你才知道这些措施为什么存在、怎么绕过。
再说攻击侧。前端是攻击者最先接触的部分，页面源码、接口调用、请求参数、存储的Token，全都在浏览器里暴露着。一个完全没有前端基础的人，看到一个登录接口都分不清参数是加密的还是明文传输的，自然也就没法判断后面会有什么问题。
我在带新人的时候，经常说一句话：不是让你成为前端开发专家，但你要能看懂前端在做什么。比如看到一段加密逻辑，你要知道它发生在哪个环节；看到接口返回的数据被动态渲染，你要想得到这可能存在什么问题。这种敏感度，全靠前端基础来支撑。
2. 浏览器安全机制：前端安全的基石
2.1 同源策略：Web安全的第一道防线
同源策略是浏览器最核心的安全机制，没有之一。简单来说，同源指的是协议、域名、端口三者完全一致。只有同源的两个页面才能互相访问对方的 DOM、读取 Cookie、发送带凭证的请求，否则就会被浏览器拦截。
用一个例子说明：某个站点运行在https://example.com:443，那么https://example.com:8080和http://example.com都不同源，更不用说其他域名了。浏览器之所以这么设计，是因为页面上的脚本默认是不可信的。如果没有同源策略，你在电商网站上登录了账号，随便打开另一个恶意页面，那个页面就能通过脚本读取你电商网站的Cookie或者页面内容，那整个互联网就乱套了。
这个机制和Web安全的关系极其密切。很多漏洞本质上是“绕过同源策略”或者“在同源范围内制造混乱”。比如跨站脚本攻击，核心就是想办法在目标站点下注入脚本，让它以站点自身的同源身份去执行任意操作。跨域资源共享（CORS）配置不当，本质上是放宽了同源策略，导致其他域可以读取本域数据。所以理解同源策略，是整个前端安全认知的地基。
2.2 浏览器其他关键安全机制
除了同源策略，浏览器里还有几个重要的安全机制，是你在学习前端安全时必须知道的。
第一个是沙箱机制。浏览器的渲染引擎、JavaScript引擎通常运行在一个受限环境里，页面脚本无法直接读写本地文件、执行系统命令。这是纵深防御的一部分，即使脚本在页面上执行了恶意逻辑，也被限制在浏览器内部。
第二个是Cookie的安全属性。服务端可以给Cookie设置HttpOnly、Secure、SameSite这些属性。HttpOnly让JavaScript无法读取Cookie，降低XSS后的凭证泄露风险；Secure要求只能通过HTTPS传输；SameSite则限制跨站请求携带Cookie，防御跨站请求伪造。这三个属性，后面分析漏洞时几乎每次都会见到。
第三个是Content Security Policy（CSP）。它允许站点主动声明“哪些来源的脚本、样式、图片是允许的”，浏览器会严格按照策略执行，不加载不信任的资源。CSP是应对注入类攻击的强力武器，不过配置不当也会引来不少问题，后面实操部分我们再细说。
这些机制看起来是浏览器厂商定的规则，但作为安全方向的人，你要把每条规则当成“边界”去理解。所谓漏洞，很多时候就是打破这些边界的手段。
3. 前端三件套里的安全细节
3.1 HTML：页面结构中的安全隐患
HTML是页面的骨架，看起来人畜无害，但安全视角下完全不是这么回事。我建议你重点留意这几个地方。
第一个是用户输入内容的渲染位置。页面里所有动态拼接进去的数据，如果直接插进HTML结构里，就很危险。比如一个搜索词，用户在搜索框输入"><script>alert(1)</script>，服务端没有过滤就拼到页面里，浏览器就会把它当作标签解析，脚本直接执行。这就是XSS形成的最基本路径。为什么强调“渲染位置”？因为同样一个用户输入，放在标签文本里、放在属性值里、放在script标签里，被利用的难度和方式完全不同。
第二个是URL跳转相关的位置。表单的action、a标签的href、iframe的src，这些地方一旦允许用户控制，就可能变成钓鱼或者Open Redirect。比如一个跳转接口https://xxx.com/redirect?url=...，如果后端不强校验URL的域名，攻击者可以构造一个跳转到恶意网站的链接，用户点击后毫无察觉。
第三个是iframe相关的风险。嵌入第三方页面如果不加sandbox和referrerpolicy这些属性，子页面可以带着父页面的信息跳转，也可能通过点击劫持等方式诱导操作。反向的场景是，如果你自己的页面可以被别人用iframe嵌进去，就要小心了，你站点上的一切操作都可能被“套”在别人的页面里，变成点击劫持攻击的目标。
这些细节，在初学阶段不要求你全部能利用，但你要做到看到HTML就能条件反射地分析哪些位置是动态的、哪些数据是不可信的。
3.2 JavaScript：攻击面最集中的地方
JavaScript是前端的灵魂，也是攻击面最集中的部分。它负责操纵DOM、发起网络请求、处理用户交互，核心的安全问题几乎都绕不开它。
首先要理解JavaScript的执行环境。在浏览器里，JavaScript运行在页面的上下文环境中，它可以读取DOM、发起fetch请求、访问localStorage和Cookie（没设HttpOnly的话）。一旦页面里注入了任意脚本，攻击者就获得了这个页面上下文中的全部权限，包括以用户身份发请求、篡改页面内容、窃取会话凭证。
然后是几个容易出问题的写法。innerHTML直接插入HTML片段，document.write写入动态内容，eval执行字符串代码，这些都属于“动态执行”的范畴。如果数据源来自用户输入，又没有严格处理，就很容易变成XSS。用innerHTML插一段<img src=x onerror=...>，图片加载失败会触发onerror事件，脚本就执行了。相比之下textContent是安全的，因为它只把它当作纯文本。
再一个值得讲的是异步请求和跨域。前端JavaScript用XMLHttpRequest或者fetch发起请求时，会受到同源策略和CORS的限制。一个页面想要调其他域的接口，必须先确认响应头里有没有Access-Control-Allow-Origin，且值符不符合要求。很多网站为了开发方便，把这个头设成*，或者直接不加限制地返回敏感数据，这就给跨域数据读取留下了隐患。
对学习Web安全的人来说，JavaScript不只是“要会看”，还得会“顺着执行逻辑推演”。页面加载了什么脚本、脚本里处理了什么数据、数据最终流向哪里，这一整条链路就是你以后寻找漏洞的依据。
3.3 CSS：容易被忽略的角落
CSS在安全里经常被人忽略，但确实有一些真实的攻击面。比如CSS注入，如果用户能控制样式内容，通过url()加载外部资源、通过@import引入恶意样式表，就可以做一些隐蔽的数据外带。过去用CSS属性选择器匹配页面内容，再配合背景图请求来窃取信息，虽然限制很多，但确实是它在安全领域露脸的经典方式。
CSS还有一个作用是视觉欺骗。利用CSS可以构造透明覆盖层、伪造可点击区域、隐藏合法按钮，这就是点击劫持攻击的基础。比如opacity:0加绝对定位，把恶意页面叠在目标网站按钮上面，用户以为自己点的是正常按钮，实际点的是攻击者布置的透明按钮。这种攻击里面CSS就是核心作案工具。
不过说实话，对第二章-1这个阶段，CSS相关的安全不必深挖，但至少要知道它也是攻击面的一部分。等到后面学前端攻防深入一些，再回头来看CSS的利用手法，会更容易举一反三。
4. HTTP协议基础：请求和响应里的门道
4.1 一个请求的生命周期
前端安全离不开HTTP协议。每个Web交互，本质上就是请求和响应的循环。你需要在浏览器里打开开发者工具，把每个请求从头到尾看一遍。
一个完整的GET请求包含请求行（方法、URL、协议版本）、请求头发送方信息（User-Agent、Referer、Cookie、Accept等），以及可选的请求体（POST/PUT请求时携带）。服务器拿到请求后，会返回状态行、响应头和响应体。状态码是判断结果的第一线索，200正常、301/302重定向、403权限不足、404不存在、500服务器异常。
这些基础知识不只是给渗透测试用的。你在排查问题时，也要学会通过请求头和响应头快速定位问题。比如你发现某个接口返回数据异常，第一件事就是看请求是否携带了正确的Cookie，响应头有没有重定向，服务器有没有返回大段的错误堆栈。这些看得多了，会有一种“手感”。
4.2 响应头里的安全信号
响应头里藏着一堆安全信号，这是我认为前端基础里最有价值的部分之一。
常见的头有Content-Type，说明返回内容的类型。如果服务端返回的是用户可控的内容，而Content-Type被设置成text/html，那么这段内容就有可能被浏览器当作HTML渲染，形成反射型XSS。反过来，如果一个接口返回的是JSON格式数据，Content-Type是application/json，同时配合X-Content-Type-Options: nosniff，浏览器就不会把响应内容当作HTML解析，也能缓解一部分问题。
Set-Cookie头直接控制Cookie的生成和属性。我在前面讲过HttpOnly、Secure、SameSite，它们都是在Set-Cookie里设置的。分析一个登录功能的时候，一定要看这个头，判断会话凭证暴露面有多大。
CSP头在前面提过，它的内容是一个“白名单策略”，比如default-src 'self'表示只能加载同源的资源。如果你看到站点配置了CSP，要进一步分析策略是否足够严格。很多站点的CSP写得特别宽松，比如允许unsafe-inline，那CSP基本就是形同虚设。
响应头里的安全配置，既是防御机制的体现，也是你判断一个系统对安全重视程度的直接参考。养成看响应头的习惯，非常值得。
4.3 HTTPS与证书的认知
HTTPS在Web安全里的地位不用多说，它解决的是传输过程中的机密性和完整性。但很多人对HTTPS的理解停留在“加了锁就是安全”，这是不对的。
HTTPS背后的证书体系同样重要。证书由证书颁发机构（CA）签发，浏览器在建立连接时会验证证书是否可信，包括域名匹配、有效期、签发链是否合法。如果证书无效，浏览器会给出警告。但对于攻击者来说，如果他能让用户访问的域名流量经过自己的代理，或者用户在无意识状态下安装了恶意CA证书，那么流量依然可以被解密。所以HTTPS不是万能的，它保护的是“传输过程”，但保护不了“用户被引导到错误的地方”。
对前端安全学习者来说，你要能分清楚HTTPS解决什么、不解决什么。遇到一个接口，先看协议是HTTP还是HTTPS；HTTPS的话证书有没有问题；证书没问题的前提下，再看业务逻辑层面有没有问题。这样一层层剥下去，才是安全分析的正确姿势。
5. 前端安全入门实操：环境搭建与动手练习
5.1 装好你的武器：浏览器开发者工具
前面讲了这么多理论，不实际操作等于白看。前端安全实操的第一步，就是把浏览器开发者工具用熟练。
打开开发者工具的快捷键通常是F12或者Ctrl+Shift+I，界面里有元素、控制台、源代码、网络、应用等几个面板。我最常使用的是网络面板和源代码面板。网络面板能看到每个请求的详细信息，包括请求头、响应头、响应体、耗时、状态码；源代码面板可以直接查看页面加载的所有JS文件，配合格式化功能分析逻辑。
我建议你的练习方法是：随便打开一个不大复杂的网站，把网络面板打开，刷新页面，从上到下看一遍请求列表。对每个请求，先看URL是什么、参数有哪些，再看响应数据是HTML还是JSON，最后看页面渲染的结果跟响应数据是否对得上。这个过程做上十天半个月，你对“一个网站是怎么工作的”就会有非常具体的感受，而不是停留在抽象概念上。
5.2 用本地环境感受同源与跨域
理解同源策略，最快的方式是自己搭一个本地环境来试。在本地建两个目录，分别启动两个本地静态服务，端口不一样就行。比如一个跑在127.0.0.1:8080，一个跑在127.0.0.1:9090。在8080服务里放一个页面，页面里用JavaScript去请求9090服务的接口，你会发现请求被浏览器拦截了，控制台报错，提示跨源读取被阻止。
这时候你再去9090服务的响应里加上Access-Control-Allow-Origin: http://127.0.0.1:8080这个头，刷新页面，请求就成功了。这就是CORS机制最直观的体验：跨域请求能不能成功读取数据，取决于目标服务器允不允许你。
不要小看这个实验。很多初学的人学了同源策略理论，但完全不知道实际效果长什么样。自己动手跑一遍，比看十篇文章都管用。
5.3 写个小页面模拟XSS触发全过程
XSS是前端安全最经典的漏洞，虽然没有独立成章，但前端基础阶段完全可以先做一个最简单的模拟实验。
在本地建一个HTML文件，里面写一个输入框和一个按钮，点击按钮后把输入框里的内容用innerHTML插入到页面里。你先输入正常文字，比如“你好”，没问题，插入的是文本。然后输入<img src=x onerror=alert(1)>，页面直接弹窗，脚本执行了。这个过程非常直观地让你看到：用户输入被当作HTML解析了，代码执行了。
这个实验的价值在于理解“输入”和“输出”的关系。输入框只是入口，真正决定是否触发漏洞的是数据渲染到页面的位置和方式。你用innerHTML插入了用户输入，就是在告诉浏览器“把这段内容当作HTML解析”。理解了这一点，之后再学XSS的各种绕过，就有基础了。
6. 常见问题排查与新手避坑
6.1 请求“被阻止”到底怎么回事
实操中新人最容易困惑的一个现象：页面发请求，控制台报错，提示类似“CORS policy”之类的内容，第一反应是“是不是被WAF拦截了”？其实多数情况下，跨域报错是浏览器层面的拦截，而不是服务器拒绝了请求。请求可能已经发出去了，服务器也处理了，但浏览器发现响应头里没有合适的Access-Control-Allow-Origin，就把响应数据扣下不给页面脚本读取。
区分这个问题的思路也很简单：在网络面板里如果能看得到这条请求以及它的响应状态码，说明请求确实到了服务器并返回了结果，问题在浏览器读取阶段。如果请求压根没出现，或者状态码不对，那才是网络或服务端的问题。这个排查逻辑，在以后所有Web开发和安全测试里都能用上。
6.2 开发者工具看不到页面源码里的某段代码
有时候你想在源代码面板里找一段页面上的逻辑，怎么都找不到。排除混淆压缩的情况，最常见的原因是页面内容是动态渲染的：JavaScript先请求接口拿到数据，再通过操作DOM把内容插入页面。你在浏览器里“查看网页源代码”只能看到最初的HTML模板，看不到动态插进去的内容。
正确的做法是打开元素面板，右键选择“检查”，或者直接查看DOM结构。这一点对漏洞分析格外重要，因为很多漏洞就藏在动态渲染的数据里，只看静态源码是永远找不到的。习惯用开发者工具看DOM树，而不是依赖查看源代码，这是从普通用户转变成安全分析者的一个明显标志。
6.3 学习路径上的几个常见偏差
带过不少人之后，我发现新手在前端基础阶段会有几个典型偏差。一个是不重视基础，觉得HTML、JavaScript自己都懂，结果真正分析时看不懂压缩混淆的代码，不会打断点调试。另一个是过度追求攻击效果，上来就想搞个弹窗、搞个反弹会话，结果连请求参数都没看明白。还有一个是只记结论不记原理，比如知道innerHTML危险，但不知道它为什么危险，换个场景就认不出来了。
我的建议是，这一阶段不要图快。把每一个基础知识点都亲手做一遍实验，哪怕只是改一行代码看效果。实验是理解原理的最短路径，没有亲自动手的过程，后面学到越深，地基越不稳。网络安全的进阶靠的是积累，基础阶段多花的时间，后面都能加倍赚回来。
6.4 一个值得养成的分析习惯
最后分享一个我自己长期受益的习惯：拿到一个陌生站点，先不要急着看功能，而是打开开发者工具，从网络面板按时间顺序浏览整个页面的加载流程。哪些请求先发起、哪些后发起、哪些接口返回了敏感字段、哪些响应头配置有问题，这个过程中你会产生大量问号。把这些问号记录下来，一个个去查，这是学习Web安全最有效率的节奏。
别怕问题太多，问号就是你最重要的学习动力。前端基础的章节到这里不是终点，后面第二章后续的课程，我们会在这个基础上继续深入请求分析、漏洞原理和实战思路。你在这里建立起来的感觉，会在后面的每一个实验里反复派上用场。
