WAF là gì? Web Application Firewall bảo vệ website

Web Application Firewall (WAF) là lớp kiểm soát đặt trước website hoặc API để kiểm tra lưu lượng HTTP/HTTPS và quyết định request nào được phép đi tiếp, request nào cần challenge, rate limit hoặc chặn. Khác với firewall mạng vốn tập trung vào IP, port và protocol, WAF hiểu nhiều tín hiệu ở tầng ứng dụng như URL, method, header, cookie, query string và một phần request body.

Vai trò đúng của WAF không phải là “vá” một ứng dụng có lỗ hổng. WAF là lớp giảm rủi ro ở biên: nó có thể chặn nhiều mẫu tấn công phổ biến, làm chậm bot hoặc abuse và tạo thêm telemetry để đội vận hành điều tra. Những lỗi authorization, business logic hoặc cấu hình backend vẫn phải được xử lý tại ứng dụng và hạ tầng.

WAF nằm ở đâu trong đường đi của request?

Một mô hình phổ biến là:

Client / Bot / Attacker
        ↓
DNS / CDN / Reverse Proxy
        ↓
       WAF
        ↓
Load Balancer / Web Server
        ↓
Application / API
        ↓
Database / Internal Services

Trong mô hình cloud hoặc CDN, WAF thường chạy ở edge trước origin. Trong mô hình self-hosted, WAF có thể là reverse proxy, module trên web server hoặc appliance riêng. Điểm quan trọng là traffic cần thực sự đi qua lớp WAF; nếu attacker vẫn truy cập trực tiếp origin thì phần bảo vệ ở edge có thể bị bypass. Vì vậy WAF phải đi cùng với kiểm soát origin protection, firewall và kiến trúc mạng phù hợp. Một case thực tế về failure mode này là attacker bypass CDN/WAF bằng Origin IP.

WAF kiểm tra request như thế nào?

WAF áp dụng một hoặc nhiều tập rule lên request. Theo tài liệu OWASP, WAF là application firewall dành cho HTTP application và thường được dùng để phát hiện hoặc chặn các mẫu tấn công web phổ biến như SQL injection và cross-site scripting. Các nền tảng hiện đại có thể kết hợp nhiều tín hiệu hơn: rule do nhà cung cấp quản lý, rule tùy chỉnh, rate limiting, bot/attack score hoặc challenge.

Match request properties: IP, ASN, quốc gia, hostname, path, method, header, cookie, query parameter hoặc body.
Đánh giá rule: request được so với managed rules và custom rules theo thứ tự xử lý của nền tảng.
Thực hiện action: log, allow, skip, challenge, rate limit hoặc block tùy policy.
Ghi telemetry: event, rule ID, action, source, path và các thuộc tính request phục vụ tuning hoặc điều tra.

Không nên hiểu WAF như một bộ chữ ký tĩnh duy nhất. Mỗi nền tảng có engine và thứ tự xử lý riêng. Ví dụ tài liệu Cloudflare hiện mô tả các lớp custom rules, rate limiting và managed rules là các phase riêng, vì vậy cùng một request có thể chịu nhiều control trước khi đến origin.

WAF có thể bảo vệ website khỏi những gì?

WAF hữu ích nhất khi request độc hại có đặc điểm có thể quan sát được tại HTTP layer. Các use case thường gặp gồm:

giảm một số mẫu SQL injection, XSS và request bất thường dựa trên rule/signature;
chặn request tới path, method hoặc endpoint không được phép theo policy;
rate limit login, search, API hoặc endpoint tốn tài nguyên;
challenge hoặc hạn chế bot/automation có dấu hiệu abuse; xem thêm Bot Protection cho website;
giảm một phần HTTP flood hoặc Layer 7 DDoS khi nền tảng có đủ capacity và tín hiệu;
triển khai virtual patch tạm thời cho một lỗ hổng đã biết trong lúc chờ sửa ứng dụng;
tạo log để nhận biết pattern tấn công và điều chỉnh lớp phòng thủ.

Đối với DDoS, WAF chỉ là một phần của thiết kế. Volumetric attack hoặc attack làm bão hòa đường truyền cần hạ tầng upstream/CDN/DDoS mitigation đủ năng lực. Với HTTP flood, rate limiting, bot mitigation và cache có thể quan trọng ngang hoặc hơn một rule WAF đơn lẻ. Xem thêm DDoS là gì và các dạng DDoS thường gặp; case HTTP Flood làm quá tải WordPress/PHP-FPM minh họa khi request hợp lệ về hình thức vẫn gây resource exhaustion.

WAF không bảo vệ được những gì?

Đây là ranh giới quan trọng nhất khi triển khai WAF. OWASP lưu ý WAF kém hiệu quả với các lỗi cần hiểu ngữ cảnh nghiệp vụ, đặc biệt là access control và business logic. Nếu một request trông hợp lệ ở HTTP layer nhưng người dùng không nên được phép thực hiện hành động đó, WAF thường không đủ thông tin để quyết định thay ứng dụng.

Broken access control: user A gọi đúng API nhưng lấy dữ liệu của user B.
Business logic abuse: thao tác hợp lệ bị lạm dụng theo trình tự hoặc số lượng mà WAF không hiểu đầy đủ.
Lỗ hổng trong code/backend: rule WAF có thể giảm exploitability nhưng không thay thế patch.
Credential compromise: request từ tài khoản đã bị chiếm có thể hoàn toàn hợp lệ về hình thức.
Server misconfiguration: port, service, SSH, permission hoặc secret exposure phải được xử lý ở hạ tầng.
Origin bypass: nếu origin public trực tiếp, attacker có thể bỏ qua WAF ở CDN/edge.

Vì vậy WAF nên được xem là một control trong mô hình defense in depth. Ở lớp server, hãy duy trì Server Security, giảm attack surface và áp dụng network firewall thay vì kỳ vọng WAF xử lý mọi vấn đề.

WAF khác firewall server, CDN và rate limiting ở đâu?

Control	Nhìn thấy chủ yếu	Mục tiêu chính	Ví dụ
WAF	HTTP/HTTPS request	Lọc traffic ở tầng ứng dụng	Chặn pattern SQLi/XSS, rule theo path/header
Firewall server	IP, port, protocol, connection	Giảm network exposure	Chỉ cho phép 80/443 từ reverse proxy
CDN	Request/response và cacheable content	Phân phối nội dung, hấp thụ traffic, giảm tải origin	Cache static assets ở edge
Rate limiting	Tần suất request theo key	Giới hạn abuse hoặc burst	Giới hạn request tới login/API; xem case Bot Traffic được kiểm soát bằng Rate Limiting

Các lớp này bổ sung cho nhau chứ không thay thế nhau. Nếu cần phân biệt sâu về boundary và tình huống sử dụng, xem WAF khác Firewall Server như thế nào? Với rate limiting, cùng một con số threshold chưa chắc mang cùng semantics giữa các nền tảng; Security Lab Cloudflare vs AWS WAF Rate Limiting phân tích khác biệt về counting, aggregation, window và enforcement.

Managed Rules và Custom Rules

Hai nhóm rule thường gặp là managed rules và custom rules. Managed rules do nhà cung cấp duy trì để bao phủ attack pattern hoặc vulnerability phổ biến. Custom rules do đội vận hành viết cho context riêng của website, ví dụ chỉ cho phép một endpoint từ IP của webhook provider hoặc challenge traffic bất thường tới một path nhạy cảm.

Managed rules giúp có baseline nhanh nhưng không hiểu đầy đủ ứng dụng của bạn. Custom rules cho độ chính xác theo context nhưng tạo thêm trách nhiệm vận hành: review logic, test, theo dõi false positive và dọn rule cũ. Phần lựa chọn và trách nhiệm vận hành được tách riêng tại Managed Rules và Custom Rules.

False positive: khi WAF chặn nhầm traffic hợp lệ

Một rule có thể match dữ liệu hợp lệ nhưng trông giống payload tấn công. Ví dụ nội dung bài viết, truy vấn tìm kiếm, JSON API hoặc checkout payload chứa ký tự đặc biệt có thể kích hoạt rule. Đây là false positive.

Không nên xử lý bằng cách tắt toàn bộ WAF hoặc allowlist quá rộng. Quy trình an toàn hơn là xác định chính xác rule, endpoint, parameter và request hợp lệ bị ảnh hưởng; sau đó giảm scope exception tới mức tối thiểu và kiểm thử lại attack case. Xem quy trình chi tiết tại cách xử lý WAF false positive và case WAF False Positive làm Checkout/API trả 403.

Ba mô hình triển khai WAF phổ biến

1. Cloud/CDN WAF

Traffic được proxy qua mạng của nhà cung cấp trước khi đến origin. Mô hình này thuận lợi cho global edge capacity, DDoS mitigation, bot/rate limiting và triển khai nhanh. Đổi lại, origin phải được khóa phù hợp để không bị truy cập trực tiếp.

2. Reverse proxy hoặc appliance riêng

WAF chạy trên một lớp proxy/appliance trước application. Mô hình này cho kiểm soát sâu hơn về network path nhưng đội vận hành phải tự chịu trách nhiệm về capacity, HA, TLS, patch và failure mode.

3. Host-based/module WAF

WAF được tích hợp ngay trên web server hoặc host. Cách này có thể phù hợp với một số kiến trúc nhỏ hoặc yêu cầu đặc thù, nhưng không tạo được lớp hấp thụ traffic ở xa origin và có thể cạnh tranh tài nguyên với chính ứng dụng khi bị tấn công.

Triển khai WAF mà không làm hỏng website

Rủi ro vận hành lớn nhất thường không phải thiếu rule mà là bật rule quá mạnh ngay từ đầu. Một rollout an toàn nên đi theo chuỗi quan sát → thử nghiệm → giới hạn scope → enforcement → read-back.

Inventory application: hostname, API, path nhạy cảm, login, checkout, webhook, upload, search và traffic machine-to-machine.
Thiết lập baseline: bật logging/analytics để hiểu normal traffic trước khi block mạnh.
Ưu tiên managed protection: bắt đầu với baseline rule set phù hợp, không tự viết hàng loạt custom rule khi chưa có evidence.
Test critical flow: login, register, checkout, payment callback, API, upload và admin workflow.
Enforce theo scope: block/challenge từng nhóm rule hoặc endpoint, tránh thay đổi sitewide không quan sát được.
Read-back telemetry: kiểm tra event sau thay đổi để phát hiện false positive hoặc bypass.
Rollback rõ ràng: mỗi rule/exception cần biết cách disable hoặc phục hồi cấu hình trước đó.

Quy trình triển khai đầy đủ được tách thành bài Cách triển khai WAF cho website mà không làm lỗi chức năng.

Khi nào website nên cân nhắc WAF?

Không có một ngưỡng traffic cố định để kết luận “website này cần WAF”. Quyết định nên dựa vào threat model, exposure và khả năng vận hành. WAF có giá trị cao hơn khi website có bề mặt HTTP lớn, endpoint nhạy cảm hoặc đang chịu abuse thực tế.

website có login, admin, checkout, form hoặc API public;
ứng dụng thường xuyên bị scan hoặc exploit attempt;
cần virtual patch trong thời gian ngắn trước khi ứng dụng được sửa;
có bot, scraping, credential stuffing hoặc HTTP flood;
origin cần được đặt sau một lớp edge/reverse proxy có policy rõ;
đội vận hành có khả năng theo dõi event và xử lý false positive.

Nếu chưa rõ mức độ cần thiết, hãy dùng checklist trong Khi nào website cần WAF? thay vì chọn WAF chỉ vì đây là một control phổ biến.

Một WAF tốt cần được vận hành, không chỉ được bật

WAF không phải cấu hình “set and forget”. Ứng dụng thay đổi endpoint, plugin, API schema và traffic pattern; rule set của nhà cung cấp cũng thay đổi. Vì vậy cần định kỳ review rule hit, exception, blocked legitimate traffic, attack trend và những path có mức rủi ro cao.

Điểm kiểm tra quan trọng gồm: rule nào đang block nhiều nhất, endpoint nào tạo false positive, exception nào đã quá rộng, request nào đang bypass WAF, origin có còn public trực tiếp không và telemetry có đủ để điều tra hay không. Khi cluster này hoàn chỉnh, WAF Maintenance Checklist là owner cho công việc định kỳ.

Checklist ngắn để đánh giá WAF

Traffic public có thực sự đi qua WAF không?
Origin có chặn truy cập trực tiếp ngoài các proxy/edge hợp lệ không?
Managed rules nào đang bật và action hiện tại là gì?
Custom rule nào tồn tại và owner của từng rule là ai?
Các flow quan trọng đã được regression test sau khi bật WAF chưa?
Có dashboard/log để xem rule hit và false positive không?
Exception có giới hạn theo hostname/path/parameter/source hợp lý không?
Rate limiting hoặc bot control có tách khỏi WAF rule thuần túy không?
Có rollback procedure khi rule làm hỏng login, checkout hoặc API không?

Kết luận

WAF là lớp kiểm soát HTTP/HTTPS đặt trước web application để phát hiện và giảm nhiều dạng traffic không mong muốn. Giá trị lớn nhất của WAF xuất hiện khi nó được đặt đúng network path, có managed/custom rule phù hợp, được theo dõi bằng telemetry và được vận hành cùng firewall, server hardening, rate limiting, DDoS protection và sửa lỗi tại ứng dụng.

Nếu đang bắt đầu từ con số 0, thứ tự hợp lý là: hiểu boundary giữa WAF và firewall → đánh giá website có thực sự cần WAF → triển khai ở chế độ có quan sát → test critical flow → mới tăng mức enforcement.

Nguồn tham khảo

Dịch vụ liên quan: Nếu bạn cần triển khai hoặc vận hành chuyên sâu, xem dịch vụ WAF & DDoS Protection.