Vì sao không nên lưu thông tin nhạy cảm trong trình duyệt?

Chủ đề: Bảo mật trình duyệt, mật khẩu, cookie, autofill, localStorage, session token
Góc nhìn: Phân tích chuyên đề dựa trên rủi ro thực tế, không giật tít và không tuyệt đối hóa vấn đề
Kết luận ngắn: Trình duyệt là nơi tiện lợi để đăng nhập, nhưng không nên xem nó như “két sắt” cho mọi loại dữ liệu. Những thông tin như mật khẩu tài khoản quan trọng, thẻ thanh toán, cookie phiên đăng nhập, token, khóa API, mã khôi phục 2FA, seed phrase ví tiền số hoặc dữ liệu định danh cá nhân không nên lưu trực tiếp trong trình duyệt.

---

1. Bối cảnh: vì sao chủ đề này đáng chú ý?

Nhiều video cảnh báo bảo mật hiện nay thường cho thấy một ý chính: trình duyệt không chỉ là công cụ để mở website, mà còn là nơi lưu rất nhiều dữ liệu cá nhân. Với Chrome, Edge, Firefox hoặc các trình duyệt dựa trên Chromium, hồ sơ người dùng có thể chứa lịch sử duyệt web, cookie, dữ liệu tự động điền, mật khẩu đã lưu, phiên đăng nhập, tiện ích mở rộng, dữ liệu site trong localStorage/IndexedDB và nhiều metadata khác.

Điểm cần hiểu đúng là: trình duyệt hiện đại thường có cơ chế mã hóa hoặc bảo vệ dữ liệu, nhưng điều đó không đồng nghĩa “dữ liệu không thể bị lấy”. Nếu thiết bị đã nhiễm mã độc, bị cài extension độc hại, bị người khác truy cập trực tiếp, hoặc tài khoản đồng bộ bị chiếm, những dữ liệu này có thể trở thành mục tiêu.

Ảnh minh họa: Mô phỏng hành vi lừa đảo/phishing nhằm lấy thẻ và tiền. Nguồn: Wikimedia Commons, tác giả Mohamed Hassan, public domain.
Nguồn ảnh: https://commons.wikimedia.org/wiki/File:Scam-phishing-fraud-email-attack-mail-online-system-cybercrime-information-access-credit-money-hack-hacker-laptop-malware-password-protection-software-steal-text-graphic-design-illustration-Material-property-techno.jpg

---

2. “Lưu thông tin trong trình duyệt” gồm những gì?

Khi nói “không nên lưu thông tin ở trình duyệt”, cần tách ra thành nhiều nhóm khác nhau:

2.1. Mật khẩu đã lưu

Đây là nhóm phổ biến nhất. Chrome, Edge và Firefox đều có trình quản lý mật khẩu tích hợp. Các trình duyệt có thể lưu username, password, passkey, và tự động điền khi người dùng quay lại website. Google, Microsoft và Mozilla đều mô tả password manager của họ như một tính năng giúp lưu và điền mật khẩu thuận tiện trên nhiều thiết bị.

Điểm rủi ro là mật khẩu nằm trong cùng môi trường với trình duyệt, cookie, extension, lịch sử đăng nhập và tài khoản đồng bộ. Nếu môi trường đó bị xâm nhập, attacker có thể không cần “bẻ khóa” website; họ có thể cố lấy dữ liệu đăng nhập hoặc phiên đăng nhập đang còn hiệu lực.

2.2. Cookie và session token

Cookie phiên đăng nhập là dữ liệu giúp website nhận ra bạn đã đăng nhập. Với nhiều cuộc tấn công, kẻ xấu không nhất thiết cần mật khẩu nếu có thể chiếm cookie/session token còn hiệu lực. Đây là lý do các nhóm mã độc đánh cắp thông tin thường nhắm vào cookie trình duyệt, token đăng nhập và dữ liệu phiên.

2.3. Autofill: thẻ, địa chỉ, số điện thoại, email

Trình duyệt có thể lưu thông tin tự động điền như tên, địa chỉ, số điện thoại, email, số thẻ thanh toán hoặc thông tin giao hàng. Dữ liệu này tiện cho mua hàng, nhưng nếu máy bị dùng chung, bị nhiễm mã độc hoặc bị phishing, nó có thể làm tăng mức thiệt hại.

2.4. localStorage, sessionStorage và IndexedDB

Đây là phần quan trọng với lập trình web. Web Storage API cho phép website lưu dữ liệu dạng key/value trong trình duyệt. Theo MDN, localStorage có thể lưu dữ liệu không có thời hạn tự hết hạn, còn sessionStorage gắn với phiên trang hiện tại. Chính vì dữ liệu này nằm ở phía client, nó không phù hợp để lưu bí mật dài hạn như JWT quan trọng, refresh token, API key, dữ liệu cá nhân nhạy cảm hoặc session identifier.

OWASP khuyến nghị không lưu session identifier trong localStorage vì dữ liệu này luôn có thể bị truy cập bởi JavaScript chạy trong cùng origin. Nếu website có lỗi XSS, script độc hại có thể đọc dữ liệu này.

---

3. Lý do không nên lưu dữ liệu nhạy cảm trong trình duyệt

3.1. Trình duyệt là “điểm tập trung dữ liệu”

Một trình duyệt không chỉ biết bạn đang mở trang nào. Nó còn có thể chứa lịch sử truy cập, cookie, cache, dữ liệu tự động điền, tài khoản đã đăng nhập, extension và dữ liệu của từng website. Khi một nơi chứa quá nhiều dữ liệu, nó trở thành mục tiêu hấp dẫn.

Nói cách khác: nếu một attacker lấy được quyền đọc dữ liệu hồ sơ trình duyệt, họ có thể có nhiều hơn một mật khẩu. Họ có thể có cả lịch sử hoạt động, dấu hiệu tài khoản nào bạn dùng, website nào bạn hay truy cập, địa chỉ email nào là email chính, và phiên đăng nhập nào còn sống.

3.2. Mã độc đánh cắp thông tin thường nhắm thẳng vào trình duyệt

Các loại infostealer hiện đại thường được thiết kế để lấy mật khẩu, cookie, dữ liệu autofill, ví tiền số, extension và token từ thiết bị đã nhiễm mã độc. SentinelOne mô tả infostealer là loại mã độc có thể trích xuất mật khẩu, session cookies và dữ liệu trình duyệt từ hệ thống bị nhiễm. Đây là rủi ro thực tế, không chỉ là giả thuyết.

Điểm nguy hiểm là nhiều người nghĩ “tôi có bật 2FA nên an toàn”. 2FA giúp giảm rủi ro, nhưng nếu attacker lấy được cookie phiên đăng nhập còn hiệu lực thì họ có thể cố vượt qua bước đăng nhập thông thường trong một số tình huống.

3.3. Cookie phiên có thể làm yếu tác dụng của mật khẩu và 2FA

Mật khẩu là thứ dùng để tạo phiên đăng nhập. Sau khi đăng nhập thành công, website thường cấp cookie hoặc token để trình duyệt duy trì trạng thái đăng nhập. Nếu token đó bị lấy khi còn hiệu lực, attacker có thể không cần biết mật khẩu ngay lập tức.

Vì vậy, khi nói về an toàn tài khoản, chỉ hỏi “mật khẩu có mạnh không?” là chưa đủ. Cần hỏi thêm: cookie được bảo vệ thế nào, token sống bao lâu, thiết bị có sạch không, extension có đáng tin không, và phiên đăng nhập cũ có được thu hồi khi đổi mật khẩu không.

3.4. localStorage không phù hợp để chứa bí mật xác thực

Với website/app tự phát triển, nhiều người có thói quen lưu JWT hoặc token vào localStorage vì dễ dùng. Đây là lựa chọn tiện nhưng rủi ro. OWASP cảnh báo không lưu session identifier trong localStorage vì JavaScript luôn có thể truy cập. Nếu trang bị XSS, token trong localStorage có thể bị đọc và gửi ra ngoài.

Cách an toàn hơn thường là dùng cookie có thuộc tính HttpOnly, Secure, SameSite, kết hợp token ngắn hạn, refresh token được kiểm soát, CSP, chống XSS và cơ chế thu hồi phiên.

3.5. Extension là một lớp rủi ro riêng

Tiện ích mở rộng có thể cần quyền đọc/ghi dữ liệu trên website. Một extension độc hại, bị bán lại, bị cập nhật thành mã độc, hoặc có quyền quá rộng có thể trở thành cửa hậu trong trình duyệt. Ngay cả khi trình duyệt tốt, extension tệ vẫn có thể làm hệ thống yếu đi.

Với người dùng phổ thông, nguyên tắc đơn giản là: càng ít extension càng tốt, chỉ cài từ nguồn uy tín, đọc kỹ quyền truy cập, xóa extension không còn dùng và tránh extension lạ có quyền “đọc và thay đổi dữ liệu trên tất cả website”.

3.6. Đồng bộ trình duyệt làm tiện hơn nhưng cũng mở rộng bề mặt rủi ro

Đồng bộ mật khẩu, bookmark, lịch sử, extension và dữ liệu trình duyệt giúp dùng nhiều thiết bị tiện hơn. Nhưng nếu tài khoản đồng bộ bị chiếm, hoặc một thiết bị trong chuỗi đồng bộ bị nhiễm mã độc, rủi ro có thể lan rộng.

Không nên hiểu rằng sync là xấu. Vấn đề là sync biến dữ liệu trình duyệt thành dữ liệu đa thiết bị. Vì vậy cần bật 2FA cho tài khoản Google/Microsoft/Mozilla, dùng mật khẩu mạnh, kiểm tra thiết bị đang đăng nhập và thu hồi thiết bị lạ.

3.7. Thiết bị dùng chung hoặc bị mở khóa là rủi ro trực tiếp

Nếu người khác có quyền dùng máy của bạn khi máy đang mở khóa, nhiều lớp bảo vệ trở nên yếu hơn. Họ có thể mở website đã đăng nhập, xem email, đổi mật khẩu tài khoản khác qua email khôi phục, hoặc xem dữ liệu tự động điền tùy cấu hình.

Với máy làm việc, máy quán net, máy mượn, máy gia đình dùng chung, không nên lưu mật khẩu hoặc thẻ thanh toán trong trình duyệt.

---

4. Có phải tuyệt đối không được dùng password manager của trình duyệt?

Không nên nói cực đoan như vậy.

Với người dùng phổ thông, lưu mật khẩu trong trình duyệt vẫn thường tốt hơn việc dùng một mật khẩu yếu cho nhiều tài khoản hoặc ghi mật khẩu vào file text không mã hóa. FTC và CISA đều khuyến nghị dùng password manager để tạo và lưu mật khẩu mạnh, duy nhất cho từng tài khoản.

Tuy nhiên, với tài khoản quan trọng như email chính, ngân hàng, ví tiền số, tài khoản quản trị website, tài khoản cloud, tài khoản công ty, tài khoản developer, GitHub, hosting, domain, VPS, tài khoản quảng cáo hoặc thanh toán, nên dùng giải pháp mạnh hơn:

• Password manager chuyên dụng có master password mạnh.
• Bật MFA/2FA, ưu tiên app xác thực hoặc security key thay vì SMS nếu có thể.
• Dùng passkey cho dịch vụ hỗ trợ.
• Không lưu seed phrase, private key, mã khôi phục 2FA, API key hoặc token trong trình duyệt.
• Tách profile trình duyệt cho công việc quan trọng.

Nói ngắn gọn: trình duyệt đủ tiện cho tài khoản ít nhạy cảm, nhưng không nên là nơi chứa toàn bộ tài sản số quan trọng của bạn.

Ảnh minh họa: Quy tắc mật khẩu ngày càng phức tạp khiến người dùng dễ phụ thuộc vào công cụ lưu mật khẩu. Nguồn: Wikimedia Commons, ảnh chụp “The Password Game”, tác giả Neal Agarwal, được xác nhận cấp phép trên Wikimedia Commons.
Nguồn ảnh: https://commons.wikimedia.org/wiki/File:The_Password_Game_screenshot.jpg

---

5. Những thông tin không nên lưu trong trình duyệt

Tuyệt đối nên tránh

• Seed phrase ví crypto.
• Private key ví, SSH key, API key, access token, refresh token.
• Mã khôi phục 2FA.
• File chứa mật khẩu dạng .txt, .csv, .xlsx tải lên hoặc lưu trong thư mục trình duyệt/cloud không mã hóa.
• Tài khoản ngân hàng, email chính, hosting, domain, tài khoản quản trị nếu không có 2FA mạnh.
• Số thẻ, CVV, ảnh giấy tờ tùy thân.
• Dữ liệu khách hàng, dữ liệu nội bộ công ty hoặc dữ liệu người dùng nếu bạn là developer/admin.

Có thể cân nhắc nhưng phải thận trọng

• Mật khẩu tài khoản ít quan trọng, miễn là mật khẩu duy nhất và có 2FA nếu có.
• Địa chỉ giao hàng trên máy cá nhân đã khóa màn hình và không dùng chung.
• Thẻ thanh toán ảo hoặc thẻ có giới hạn, nếu bạn chấp nhận mức rủi ro tiện lợi.

---

6. Khuyến nghị cho người dùng cá nhân

6.1. Tắt lưu mật khẩu trong trình duyệt cho tài khoản quan trọng

Không nhất thiết phải xóa mọi thứ ngay lập tức, nhưng nên bắt đầu từ tài khoản quan trọng: email chính, ngân hàng, ví, cloud, hosting, domain, tài khoản công việc, GitHub, tài khoản quảng cáo và tài khoản có quyền thanh toán.

6.2. Dùng password manager chuyên dụng

Một password manager chuyên dụng thường cho phép tạo mật khẩu mạnh, lưu vault riêng, có master password, hỗ trợ 2FA, chia sẻ an toàn hơn, kiểm tra mật khẩu bị lộ và tách biệt khỏi dữ liệu trình duyệt. Không có công cụ nào an toàn tuyệt đối, nhưng tách vault mật khẩu khỏi trình duyệt giúp giảm việc mọi thứ nằm trong một nơi.

6.3. Ưu tiên passkey và security key

Passkey giúp giảm rủi ro phishing vì đăng nhập gắn với domain hợp lệ và thiết bị/khóa xác thực. Với tài khoản cực kỳ quan trọng, security key phần cứng là lựa chọn đáng cân nhắc.

6.4. Bật 2FA đúng cách

FTC nhấn mạnh rằng mật khẩu mạnh vẫn có thể bị đánh cắp, vì vậy 2FA/MFA giúp thêm một lớp bảo vệ. Nếu có lựa chọn, nên ưu tiên app xác thực hoặc security key. SMS tốt hơn không có gì, nhưng không phải lựa chọn mạnh nhất.

6.5. Kiểm tra và xóa dữ liệu đã lưu

Nên định kỳ kiểm tra:

• Mật khẩu đã lưu trong Chrome/Edge/Firefox.
• Thẻ thanh toán đã lưu.
• Địa chỉ, số điện thoại, email trong autofill.
• Cookie và phiên đăng nhập cũ.
• Extension không dùng.
• Thiết bị đang đăng nhập tài khoản Google/Microsoft/Mozilla.

6.6. Bảo vệ thiết bị gốc

Dù dùng công cụ nào, nếu thiết bị bị nhiễm mã độc thì rủi ro vẫn cao. Cần cập nhật hệ điều hành, trình duyệt, phần mềm; không chạy file lạ; không cài phần mềm crack; bật mã hóa ổ đĩa; đặt mật khẩu máy; khóa màn hình khi rời máy; và dùng phần mềm bảo vệ phù hợp.

Ảnh minh họa: Mô phỏng khái niệm “vault” của password manager chuyên dụng. Nguồn: Wikimedia Commons, file 1Password login screenshot.webp.
Nguồn ảnh: https://commons.wikimedia.org/wiki/File:1Password_login_screenshot.webp

---

7. Khuyến nghị cho lập trình viên web

Nếu bạn đang xây dựng website hoặc ứng dụng web, vấn đề không chỉ là người dùng lưu mật khẩu ở đâu. Bạn còn phải quyết định app của bạn lưu gì trong trình duyệt của họ.

Không nên

• Không lưu refresh token dài hạn trong localStorage.
• Không lưu API key, private key, secret, mã khôi phục trong localStorage/sessionStorage.
• Không lưu dữ liệu cá nhân nhạy cảm trong browser storage nếu không thật sự cần.
• Không xem mã hóa phía client là giải pháp đầy đủ nếu key cũng nằm trong JavaScript.
• Không để token sống quá lâu mà không có cơ chế thu hồi.

Nên

• Dùng cookie HttpOnly, Secure, SameSite cho session quan trọng.
• Dùng access token ngắn hạn.
• Có cơ chế refresh token rotation và thu hồi phiên.
• Chống XSS bằng output escaping, sanitization, CSP, kiểm soát dependency.
• Không đưa secret thật vào frontend.
• Có trang quản lý phiên đăng nhập để người dùng thu hồi thiết bị lạ.
• Buộc đăng nhập lại trước thao tác nhạy cảm như đổi email, đổi mật khẩu, xuất dữ liệu, thêm phương thức thanh toán.

---

8. Bảng tóm tắt rủi ro

---

9. Kết luận

Không nên hiểu câu “đừng lưu thông tin ở trình duyệt” theo kiểu hoảng loạn rằng mọi tính năng của trình duyệt đều nguy hiểm. Cách hiểu đúng là: trình duyệt được thiết kế để tiện, còn dữ liệu nhạy cảm cần được quản lý theo mức rủi ro.

Với tài khoản ít quan trọng, trình quản lý mật khẩu tích hợp có thể chấp nhận được nếu bạn dùng mật khẩu riêng cho từng tài khoản và bật 2FA. Nhưng với tài khoản quan trọng, thông tin thanh toán, token, cookie, khóa API, mã khôi phục, seed phrase và dữ liệu cá nhân nhạy cảm, không nên đặt niềm tin hoàn toàn vào trình duyệt.

Nguyên tắc thực tế: mật khẩu nên nằm trong password manager; phiên đăng nhập nên ngắn và có thể thu hồi; token không nên nằm trong localStorage; thông tin tài chính và khóa bí mật không nên nằm trong browser profile.

---

Nguồn tham khảo

1. OWASP — HTML5 Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html
2. MDN Web Docs — Web Storage API: https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API
3. CISA — Use Strong Passwords: https://www.cisa.gov/secure-our-world/use-strong-passwords
4. FTC — Creating Strong Passwords and Other Ways To Protect Your Accounts: https://consumer.ftc.gov/articles/creating-strong-passwords-and-other-ways-protect-your-accounts
5. FTC — Use Two-Factor Authentication To Protect Your Accounts: https://consumer.ftc.gov/articles/use-two-factor-authentication-protect-your-accounts
6. Google Password Manager: https://passwords.google/
7. Microsoft Support — View or edit your passwords in Microsoft Password Manager: https://support.microsoft.com/en-us/accounts-billing/manage/view-or-edit-your-passwords-in-microsoft-password-manager
8. Mozilla Firefox Password Manager: https://www.firefox.com/en-US/features/password-manager/
9. SentinelOne — What Is an Infostealer?: https://www.sentinelone.com/cybersecurity-101/cybersecurity/infostealer/
10. CISA StopRansomware Guide: https://www.cisa.gov/stopransomware/ransomware-guide