HTML5 新特性、語義化
新特性
新的 DOCTYPE 聲明<!DOCTYPE html>
新增 vedio 和 audio 標簽
繪畫
canvas-
語意化更好內(nèi)容元素
article、footer赊时、header、nav沐序、section
-
表單控件
calendar、date堕绩、time策幼、email、url
-
新的技術(shù)
webworker奴紧、websocket特姐、Geolocation
本地離線存儲
localStorage長期存儲數(shù)據(jù)，瀏覽器關(guān)閉后數(shù)據(jù)不丟失sessionStorage的數(shù)據(jù)在瀏覽器關(guān)閉后自動刪除
語義化
用正確的標簽做正確的事
計算機能快速讀懂內(nèi)容黍氮，高效處理信息唐含，對搜索引擎更友好
頁面結(jié)構(gòu)清晰
有利于 SEO
方便其他設(shè)備解析
便于團隊開發(fā)和維護浅浮，語義化更具有可讀性
區(qū)分 HTML 和 HTML5
- 聲明不同，HTML5<!DOCTYPE html>捷枯，HTML 很長一段
- 結(jié)構(gòu)語義不同滚秩，HTML5 有很多新的標簽，而 HTML 沒有體現(xiàn)結(jié)構(gòu)語義的標簽淮捆，用<div id="header"></div>來表示網(wǎng)站頭部
DOCTYPE 作用
<!Doctype>聲明位于文檔中的最前面郁油，處于<html>標簽之前。告知瀏覽器的解析器攀痊，用什么文檔類型規(guī)范來解析這個文檔桐腌。
HTML5 離線緩存原理
用戶沒有網(wǎng)絡(luò)時可正常訪問站點或應(yīng)用，當用戶有網(wǎng)絡(luò)時苟径，更新用戶機器上的緩存文件
原理：離線緩存技術(shù)基于
.appcache文件案站，通過此文件的解析清單離線存儲資源，這些資源像 cookie 一樣被存儲下來棘街，之后再網(wǎng)絡(luò)離線狀態(tài)下蟆盐，瀏覽器會通過被離線存儲的數(shù)據(jù)進行頁面展示-
使用：頁面頭部添加 manifest 屬性，在 cache.mainfest 文件的編寫離線存儲的資源
CACHE MANIFEST #v0.11 CACHE: js/app.js css/style.css NETWORK: resourse/logo.png FALLBACK: / /offline.html
處理 HTML5 離線儲存資源
- 在線時遭殉，瀏覽器發(fā)現(xiàn) html 頭部有 manifest 屬性時會請求 manifest 文件舱禽，如果是第一次訪問就會根據(jù) manifest 文件內(nèi)容下載相應(yīng)的資源進行離線存儲，如果已經(jīng)訪問過恩沽，瀏覽器使用緩存的資源加載頁面，同時會對比新的 mainfest 文件和舊的 mainfest 是否有改變翔始，決定是否重新下載
- 離線時罗心，瀏覽器直接使用離線緩存資源
cookie，sessionStorage 和 localStorage 的區(qū)別
區(qū)別
cookie 是網(wǎng)站為了標示用戶身份存在用戶本地終端上的數(shù)據(jù)（經(jīng)過加密）
cookie 數(shù)據(jù)始終在同源的 htto 請求中攜帶（即使不需要）城瞎，即會在瀏覽器和服務(wù)器之間傳遞
sessionStorage 和 localStorage 不會自動把數(shù)據(jù)發(fā)給服務(wù)器渤闷，僅在本地保存存儲大小
cookie 大小不能超過 4k
sessionStorage 和 localStorage 也有大小要求，5m過期時間
localStorage: 永久儲存脖镀，手動刪除
sessionStorage：窗口關(guān)閉自動刪除
cookie：設(shè)置的 cookie 過期時間之前一直存在瀏覽器內(nèi)核IE: trident 內(nèi)核
Firefox：gecko 內(nèi)核
Safari：webkit 內(nèi)核
Opera：以前是 presto 內(nèi)核飒箭，Opera 現(xiàn)已改用 Google Chrome 的 Blink 內(nèi)核
Chrome：Blink(基于 webkit，Google 與 Opera Software 共同開發(fā))
理解
- 主要分成兩部分：渲染引擎(
layout engineer或Rendering Engine)和JS引擎 - 渲染引擎：負責取得網(wǎng)頁的內(nèi)容（
HTML蜒灰、XML弦蹂、圖像等等）、整理訊息（例如加入CSS等）强窖，以及計算網(wǎng)頁的顯示方式凸椿，然后會輸出至顯示器或打印機。瀏覽器的內(nèi)核的不同對于網(wǎng)頁的語法解釋會有不同翅溺，所以渲染的效果也不相同脑漫。所有網(wǎng)頁瀏覽器髓抑、電子郵件客戶端以及其它需要編輯、顯示網(wǎng)絡(luò)內(nèi)容的應(yīng)用程序都需要內(nèi)核 -
JS引擎則：解析和執(zhí)行javascript來實現(xiàn)網(wǎng)頁的動態(tài)效果 - 最開始渲染引擎和
JS引擎并沒有區(qū)分的很明確优幸，后來 JS 引擎越來越獨立吨拍，內(nèi)核就傾向于只指渲染引擎
Canvas 和 SVG 區(qū)別
- svg 繪制除的圖形元素都是獨立的 DOM 節(jié)點，能方便的綁定事件和用來修改网杆；canvas 輸出是一整幅畫布
- svg 輸出的圖形的矢量圖形羹饰，放大縮小不受影響，canvas 輸出的是標量畫布跛璧，像一張圖片一樣放大縮小會失真或者鋸齒
- svg 使用 xml 文檔來描述繪圖严里，canvas 是 HTML5 提供的繪圖 API，通過 getContent 方法獲取畫筆才可繪圖
使用 date-的好處
- 自定義屬性可以統(tǒng)一化
- 維護方便追城，頁面結(jié)構(gòu)清晰
meta 標簽
- charset 聲明文檔字符編碼
- description刹碾、keywords、author 等頁面描述
- viewport 為移動設(shè)備添加 viewport
- cache-control座柱、expires 設(shè)置頁面緩存狀態(tài)
attribute 和 property 的區(qū)別是什么迷帜？
- attribute 是 dom 元素在文檔中作為 html 標簽擁有的屬性
- property 是 dom 元素在 js 中作為對象擁有的屬性
- 對于 html 標準屬性來說，attribute 和 property 是同步的色洞，會自動更新
- 對于自定義屬性來說是不同步的
頁面顯示 HTML 過程
過程：構(gòu)建 dom 樹-->構(gòu)建 render 樹-->布局 render 樹-->繪制 render 樹
- 瀏覽器加載 html 文件戏锹，自上而下，構(gòu)建 DOM 樹
- 遇到請求外部資源（css火诸、圖片等）時锦针，不影響 DOM 樹的加載，請求時異步的
- 解析 CSS 文件構(gòu)建渲染樹置蜀，等渲染樹構(gòu)建完成奈搜，瀏覽器開始布局渲染樹并繪制到屏幕上（css 放在最上面，瀏覽器預先加載 css 后盯荤，可以不必等待 HTML 加載完畢就可以渲染頁面了）馋吗，此時會涉及：reflow 回流和 repain 重繪
- reflow 回流：DOM 節(jié)點中元素都是以盒模型的形式存在，需要瀏覽器去計算其位置和大小秋秤，此過程稱為回流
- repain 重繪：當盒模型的位置宏粤、大小及其他屬性（字體、顏色等）確定后灼卢，瀏覽器便開始繪制內(nèi)容绍哎，此過程稱為重繪
- 頁面首次訪問必然會經(jīng)歷 reflow 和 repain，這兩個過程非常消耗性能鞋真，尤其在移動設(shè)備上蛇摸，所以應(yīng)盡量減少 reflow 和 repain
- 當文檔掛載過程遇到 js 文件，html 文檔會掛起渲染的線程灿巧，等待 js 文件加載完畢并解析執(zhí)行完成赶袄，才可以恢復 html 文檔的渲染線程（JS 可能會修改 DOM揽涮，意味著，在 js 執(zhí)行完成前饿肺，后續(xù)所有資源加載可能時沒有必要的蒋困，這是 js 阻塞后續(xù)資源下載的根本原因，所以 js 會放在文檔末尾）
- JS 的解析有瀏覽器的 js 引擎完成敬辣，例如 v8 引擎
說一下強制緩存和協(xié)商緩存
緩存指在本地磁盤中對訪問過的資源保存的副本文件
-
請求過程：瀏覽器在第一次請求后緩存資源雪标，再次請求時，會進行下面兩個步驟
瀏覽器會獲取該緩存資源的 header 中的信息溉跃，根據(jù) response header 中的 expires 和 cache-control 來判斷是否命中強緩存村刨，如果命中則直接從緩存中獲取資源。如果沒有命中強緩存撰茎，瀏覽器就會發(fā)送請求到服務(wù)器嵌牺，這次請求會帶上 IF-Modified-Since 或者 IF-None-Match, 它們的值分別是第一次請求返回 Last-Modified 或者 Etag，由服務(wù)器來對比這一對字段來判斷是否命中龄糊。如果命中逆粹，則服務(wù)器返回 304 狀態(tài)碼，并且不會返回資源內(nèi)容炫惩，瀏覽器會直接從緩存獲绕У；否則服務(wù)器最終會返回資源的實際內(nèi)容他嚷，并更新 header 中的相關(guān)緩存字段蹋绽。
強緩存：不會像服務(wù)器發(fā)送請求，直接從緩存中讀取資源筋蓖，狀態(tài)為 200
Expires：過期時間卸耘，GMT（格林尼標準時間，世界標準時間扭勉，0 時區(qū)，北京處于東 8 區(qū)苛聘，所以北京時間=GMT 時間+8 小時）格式時間點字符串（Expires:Mon,18 Oct 2066 23:59:59 GMT）代表資源失效時間涂炎，瀏覽器再次請求加載資源時，如果在這個過期時間內(nèi)设哗，則命中強緩存
Cache-Control：以 max-age 值來判斷唱捣，相對時間（Cache-Control:max-age=3600）代表資源有效期為 3600s，返回頭中 Date 標識消息發(fā)送時間网梢，表示當前資源在 Date - Date + 3600s 時間段內(nèi)都有效
no-cache 不使用本地緩存震缭，使用協(xié)商緩存
no-store 直接禁止瀏覽器緩存數(shù)據(jù)，每次加載資源都會想服務(wù)器要完整的資源战虏，類似于 network 中的 disabled cache
public 可以被所有用戶緩存拣宰，包括終端用戶和 cdn 等中間件代理服務(wù)器
private 只能被終端用戶瀏覽器緩存
如果 cache-control 與 expires 同時存在的話党涕，cache-control 的優(yōu)先級高于 expires。協(xié)商緩存：由服務(wù)器決定緩存資源是否可用巡社。第一次請求時會帶著 Last-Modified 或 Etag膛堤，后續(xù)請求則會帶著對應(yīng)的請求字段 If-Modified-Since 或者 If-None-Match，若響應(yīng)頭沒有 Last-Modified 或 Etag 字段時晌该，則響應(yīng)頭也不會有對應(yīng)的字段
Last-Modified/If-Modified-Since：標記文件最后修改時間肥荔，下一次請求時，請求頭會帶上 If-Modified-Since 值就是 Last-Modified 告訴服務(wù)器本地緩存的文件最后修改時間朝群，判斷資源是否有變化燕耿，無變化時直接返回 304，瀏覽器直接使用本地緩存姜胖；有變化時正常返回請求資源內(nèi)容誉帅，新的 Last-Modified 會在 response header 中返回，并在下次請求時更新本地緩存的 Last-Modified
Etag/If-None-Match：服務(wù)器為每個資源生成一個 hash 值谭期，資源有變化值就會改變堵第，并將 ETag 字段返回給瀏覽器，服務(wù)器接收到 If-None-Match 后隧出，比較兩者是否一致來判定文件內(nèi)容是否改變踏志。每次都會返回 ETag共同點
都是從客戶端緩存中讀取資源，區(qū)別是強緩存不發(fā)請求胀瞪，協(xié)商緩存發(fā)請求區(qū)別
強緩存不需要向服務(wù)器發(fā)請求针余，協(xié)商緩存有服務(wù)器決定是否使用緩存，存在依次通信
強緩存狀態(tài)碼是 200（from cache）凄诞，而協(xié)商緩存如果命中緩存的話圆雁，狀態(tài)碼是 304（not modified）
from cache 分為 from memory cache 和 from disk cache，從內(nèi)存中獲取最快伪朽，但是是 session 級別的緩存，關(guān)閉瀏覽器之后就沒有了西土。優(yōu)先級
Cache-Control > expires > Etag > Last-Modified最后總結(jié)一下瀏覽器的三級緩存原理：
先去內(nèi)存看，如果有欣除，直接加載
如果內(nèi)存沒有杠娱，擇取硬盤獲取室叉，如果有直接加載
如果硬盤也沒有踪旷，那么就進行網(wǎng)絡(luò)請求
加載到的資源緩存到硬盤和內(nèi)存
Ctrl + F5 強制刷新的時候气破，會暫時禁用強緩存和協(xié)商緩存努咐。-
配置
// 1.服務(wù)端配置 res.setHeader('max-age': '3600 public') res.setHeader(etag: '5c20abbd-e2e8') res.setHeader('last-modified': Mon, 24 Dec 2018 09:49:49 GMT) // 2. nginx配置 add_header Cache-Control "max-age=3600"
什么是預加載和懶加載
- 預加載：提交加載資源殴胧，當用戶需要時可直接從本地緩存中渲染
- 懶加載：主要目的是作為服務(wù)器前端的優(yōu)化，減少請求次數(shù)或延遲請求
- 行為相反，一個是提前加載团滥，一個是遲緩甚至不加載
- 懶加載對服務(wù)器有一定的緩解壓力作用竿屹，而預加載會增加服務(wù)器前端壓力
- 圖片的加載是由 src 的值引起的,當對 src 賦值時瀏覽器回請求國片資源,基于這個【逆ⅲ可以利用 html5 的特性 data-xxx 保存圖片的路經(jīng),當我們需要加載圖片的時候才將 data-xxx 的值賦予 src拱燃，就能實現(xiàn)圖片的按需加載。也就是懶加載
常見 web 安全及防護原理
sql 注入原理：將 sql 插入到 web 表單提交或輸入域名或頁面請求的查詢字符串力惯，最終達到欺騙服務(wù)器進行惡意的 SQL 命令
-
xss 原理及規(guī)范：跨站腳本（cross-site scripting）攻擊指攻擊者往 web 頁面插入惡意 html 標簽或 javascript 代碼碗誉，使用戶訪問都會執(zhí)行相應(yīng)的嵌入代碼，從而獲取用戶資料等父晶。比如：攻擊者在論壇中放一個看似安全的鏈接哮缺，騙取用戶點擊后，竊取
cookie中的用戶私密信息甲喝；或者攻擊者在論壇中加一個惡意表單尝苇，當用戶提交表單的時候，卻把信息傳送到攻擊者的服務(wù)器中埠胖，而不是用戶原本以為的信任站點防御措施：
- 輸入過濾：只要有輸入的地方糠溜，就存在 xss 攻擊 1.攻擊者提交惡意代碼（前后臺都需要做過濾檢查或轉(zhuǎn)碼），2.瀏覽器執(zhí)行惡意代碼
- 利用 CSP 內(nèi)容安全策略：建立白名單直撤，告訴瀏覽器哪些外部資源可以加載和執(zhí)行非竿，只需要配置規(guī)則，如何攔截是瀏覽器自己實現(xiàn)的
- 設(shè)置 heep header 中的 Content-Security-Policy: default-src 'self' img-src child-src
- 設(shè)置 meta 標簽 http-equiv="content-Securoty-Policy"
- cookie 的 HttpOnly 禁止 js 讀取 Cookie 信息
- 通過驗證碼方法驗證用戶提交
如果還有的話谊惭，像限制用戶輸入長度汽馋，因為 js 腳本一般都是比較長的
-
csrf 原理：跨站請求偽造（cross-site request forgery），挾制用戶在當前已登錄的 web 應(yīng)用程序上執(zhí)行非本意的操作的攻擊方法圈盔。就是說冒充用戶發(fā)起請求豹芯，完成一些違背用戶意愿的請求，與 xss 不同的是驱敲，xss 是攻擊者直接對我們的網(wǎng)站 A 進行注入攻擊铁蹈，而 CSRF 是通過網(wǎng)站 B 對網(wǎng)站 A 進行滾偽造請求；例如众眨，在購物網(wǎng)站 A 點擊一個惡意鏈接 B握牧，B 請求網(wǎng)站 A 下的下單接口，結(jié)果在 A 網(wǎng)站就真的會生成一個訂單娩梨；原理是：網(wǎng)站 B 通過表單沿腰、get 請求來偽造網(wǎng)站 A 的請求，這時候請求會帶上網(wǎng)站 A 的 cookie狈定，若登陸信息保存在 cooklie 中颂龙，就實現(xiàn)了偽造攻擊
-
驗證 csrf token习蓬，目前相對成熟的方案
服務(wù)端隨機生成 token，保存在服務(wù)端 session 中措嵌，同時保存到客戶端中躲叼，客戶端發(fā)送請求時，把 token 帶到 HTTP 請求頭或參數(shù)中企巢，服務(wù)端接收到請求枫慷，驗證請求中的 token 與 session 中的是否一致。
token 可以在登錄時寫入到 cookies 中浪规，發(fā)送請求時或听，js 讀取 cookies 中的 token，并設(shè)置到 HTTP 請求頭中笋婿。 針對偽造請求的域名不是網(wǎng)站 A神帅，限制 cookie 中的 sameSite 屬性為 strict，只有同源網(wǎng)站的請求才會帶上 cookie
-
更換登錄態(tài)方案
由于 CSRF 本質(zhì)是偽造請求攜帶了保存在 cookie 中的信息萌抵，所以對 session 機制的登錄態(tài)比較不利找御，可以使用 JWT（JSON WEB TOken）方案，其 token 信息一般設(shè)置到 HTTP 請求頭中绍填，所以可以預防 CSRF 攻擊
-
XSS是獲取信息霎桅，不需要提前知道其他用戶頁面的代碼和數(shù)據(jù)包。CSRF是代替用戶完成指定的動作讨永，需要知道其他用戶頁面的代碼和數(shù)據(jù)包TOKEN 可能被竊取滔驶，可以通過 XSS 攻擊這種方式去竊取，可以結(jié)合一些其他的手段卿闹，預防 xss 攻擊
referer 字段
vue 中的 xss 防御
vue 框架已經(jīng)進行了一些 xss 防御揭糕，對于一些外來的內(nèi)容（例如接口或 url 參數(shù)），盡量用{{}}表達式顯示（{{{}}}表示不經(jīng)轉(zhuǎn)義直接輸出）锻霎，因為{{}}中的內(nèi)容進行了字符串化著角，瀏覽器不會對其中的內(nèi)容進行執(zhí)行操作；盡量避免 v-html 指令旋恼，或者先對內(nèi)容進行 xss 過濾
cookie 面試題
由于 HTTP 是無狀態(tài)協(xié)議吏口，無狀態(tài)指的是服務(wù)端對于客戶端每次發(fā)送的請求都會認為是新的一個請求，上一次會話和下一次會話沒有聯(lián)系冰更。但是很多場景需要直到上次會話和下一次會話的關(guān)系（比如登陸之后記住登陸狀態(tài)）产徊，這時就引入和 cookie 和 session 體系。
- cookie
客戶端請求服務(wù)器時蜀细，如果服務(wù)器需要記錄該用戶狀態(tài)舟铜，就通過 response Headers 像客戶端瀏覽器頒發(fā)一個 cookie，而客戶端瀏覽器會把 cookie 保存起來奠衔，當瀏覽器在請求服務(wù)器時谆刨，瀏覽器把請求的網(wǎng)址連同該 cookie 一同提交給服務(wù)器奕谭，服務(wù)器通過檢查該 cookie 來獲取用戶狀態(tài) - session
當服務(wù)器接收請求時，就從存儲在服務(wù)器上的無數(shù) session 信息中去查找客戶端請求時帶過來的 cookie 的狀態(tài)痴荐，如果服務(wù)器中沒有這條 session 信息則添加一條 session 信息
通常 cookie 中存的是 session 信息經(jīng)過計算后的唯一 id sessionid
cookie 時如何工作的
-
request
當瀏覽器發(fā)送一個請求時，瀏覽器回自動檢查是否有相應(yīng)的 cookie官册，如果有則將 cookie 添加到 Request Headers 的 Cookie 字段中（cookie 字段是很多 name=value 以分號分隔的字符串）
-
response
當服務(wù)端需要種 cookie 時生兆，在 http 請求的 Response Headers 中添加 Set-Cookie 字段，瀏覽器接收之后會自動解析識別膝宁，將 cookie 保存起來
Set-Cookle:_ _hsid_t=3eac583831cb5952_t;Path=/;Domain=360.com; Max-Age=86400
##### cookie 和 session 的區(qū)別
- 存儲位置不同
cookie 存儲在客戶瀏覽器上鸦难，而 session 數(shù)據(jù)保存在服務(wù)器上
- 存儲大小不同
一般單個 cookie 保存的數(shù)據(jù)不能超過 4 個，單個域名最多保存 20 個 cookie员淫；session 則無大小和限制
##### cookie 屬性
- Name：cookie 名
- Value：cookie 值
- Domain：cookie 的域名合蔽。如果設(shè)置.example.com，那么子域名 a.example.com 和 b.example.com介返，都可以使用.example.com 的 cookie拴事，反之則不行
- Path：允許讀取 cookie 的 url 路徑，一般設(shè)置為/
- Expires：cookie 過期時間圣蝎。不設(shè)置刃宵，則為 session 會話期，頁面退出時 cookie 失效
- HttpOnly：設(shè)置為 true 時徘公，只有 http 能讀取牲证，js 只能讀取未設(shè)置 HttpOnly 的 cookie
- Secure：標記為 Secure 的 cookie，只有 https 的請求可以攜帶
- SameSite：限制第三方 url 是否可以攜帶 cookie
- Strict：僅允許同站點請求的 cookie
- Lax：允許部分第三方請求攜帶 cookie关面，即導航到目標網(wǎng)址的 get 請求坦袍，包括超鏈接，預加載和 get 表單三種形式發(fā)送 cookie
- None：任意發(fā)送 cookie等太，需要設(shè)置 Secure捂齐，網(wǎng)站必須采用 https
- Priority：優(yōu)先級
##### 操作 cookie，js 和服務(wù)端
當設(shè)置了 HttpOnly 為 true 時缩抡，只有 http 請求讀取辛燥，不能被 js 讀取，具體表現(xiàn)為 document.cookie 讀取到的值不包含設(shè)置的 HttpOnly
js 操作 cookie 使用 document.cookie
- 讀取
document.cookie 讀取到字符串缝其，包含 cookie 的 name 和 value挎塌，需要解析
- 寫入
```js
document.cookie =
'uid=123;expires=Mon Jan 04 2022 17:42:40 GMT;path=/;secure;'
document.cookie =
'uid=123;expires=Mon Jan 04 2022 17:42:40 GMT;path=/caikuai;domain=edu.#;secure;samesite=lax'
一次只能寫入一個 cookie
-
刪除
只需要將一個已經(jīng)存在的 cookie 名字過期時間設(shè)置為過去時間即可
document.cookie = 'uid=123;expires=' + new Date(0) + ';path=/;secure;' -
修改
重新賦值，要保證 path 和 domain 兩個值不變内边，否則會添加新的 cookiedocument.cookie = 'uid=123;expires=Mon Jan 04 2082 17:42:40 GMT;path=/;secure;'
服務(wù)器端如何讀寫 cookie
-
寫 cookie
res.setHeader('Set-Cookie', ['uid=123;maxAge: 900000; httpOnly: true']) // 或者 res.cookie('uid', '123', { maxAge: 900000, httpOnly: true }) -
讀取 cookie
console.log(req.getHeader('Cookie')) // 拿到所有cookie // 或者 console.log(req.cookie.name)
查看瀏覽器是否打開 Cookie 功能
window.navigator.cookieEnabled // true
cookie 的共享策略是什么
domain 和 path 共同決定 cookie 可以被哪些 url 訪問
訪問一個 url 時榴都，如果 url 的 host 和 domain 一致或者時 domain 的子域名，并且 url 的路徑和 path 部分匹配漠其，那么 cookie 才可以被獲取
cookie 的編碼
document.cookie =
'uid=123;expires=Mon Jan 04 2022 17:42:40 GMT;path=/caikuai;domain=edu.#;secure;samesite=lax'
cookie 一般包含等號嘴高、冒號竿音、分號、空格拴驮、逗號春瞬、斜杠等特殊字符，需要對其進行編碼套啤，使用 encodeURIComponent/decodeURIComponent 操作
不使用 escape 和 encodeURI 的原因是宽气，encodeURIComponent 可以將更多字符進行編碼，比如‘/’
cookie 應(yīng)對 xss 漏洞
xss 漏洞原理是：由于未對用戶提交的表單數(shù)據(jù)或者 url 參數(shù)等數(shù)據(jù)做處理就顯示在頁面上潜沦，導致用戶提交的內(nèi)容在頁面上被作為 html 解析執(zhí)行
常規(guī)方案：對特殊字符進行滾處理萄涯，如對“<”或“>“進行轉(zhuǎn)義
cookie 設(shè)置：對用用戶利用 script 腳本采集 cookie 信息，可以將重要的 cookie 信息設(shè)置為 HttpOnly 來避免 cookie 被 js 采集
cookie 應(yīng)對 csrf 攻擊
跨站請求偽造原理：用戶登陸 A 網(wǎng)站唆鸡，然后因為某些原理訪問 B 網(wǎng)站（比如跳轉(zhuǎn)）涝影，B 網(wǎng)站直接發(fā)送一個 A 網(wǎng)站的請求進行一些危險操作，由于 A 網(wǎng)站處理登陸狀態(tài)争占，就發(fā)生了 CSRF 攻擊燃逻，核心是利用了 cookie 信息可以被跨站攜帶
常規(guī)方案：采用驗證碼或 token 等
cookie 設(shè)置：由于 CSRF 攻擊核心是利用 cookie 信息可以被跨站攜帶，可以對核心 cookie 的 SameSite 設(shè)置為 Strict 或 Lax 來避免
不同瀏覽器共享 cookie 嗎
不共享臂痕，是對立的 cookie
web 端 cookie 的設(shè)置和獲取
//寫cookie
function setCookie(name, value) {
var Days = 30
var exp = new Date()
exp.setTime(exp.getTime() + Days * 24 * 60 * 60 * 1000)
document.cookie = name + '=' + escape(value) + ';expires=' + exp.toGMTString()
}
//讀取cookie
function getCookie(name) {
var arr,
reg = new RegExp('(^| )' + name + '=([^;]*)(;|$)')
if ((arr = document.cookie.match(reg))) {
return unescape(arr[2])
} else {
return null
}
}
//刪除cookie
function delCookie(name) {
var exp = new Date()
exp.setTime(exp.getTime() - 1)
var cval = getCookie(name)
if (cval != null) {
document.cookie = name + '=' + cval + ';expires=' + exp.toGMTString()
}
}
