HTTPS và header bảo mật đạt yêu cầu là khi mọi tài nguyên trên trang đi qua HTTPS, chứng chỉ cùng phiên bản TLS còn được hỗ trợ, và máy chủ gửi đủ bộ header để trình duyệt biết được phép làm gì với trang. Bài #20 chuyển tiêu chí 164-173 thành các bước kiểm mixed content, TLS, HSTS, nosniff, chống nhúng, CSP, Referrer-Policy, Permissions-Policy, cookie quản trị và mức lộ công nghệ.
Bài dành cho SEOer, người quản trị WordPress và đội vận hành hạ tầng cần một bộ nghiệm thu có bằng chứng. Mỗi tiêu chí đi kèm giá trị header cụ thể, cách kiểm bằng dòng lệnh, lỗi thường gặp và thứ tự bật để không làm website chết giữa đường.
1. HTTPS và header bảo mật trong SEO WordPress là gì?
HTTPS là lớp mã hóa giữa trình duyệt và máy chủ, còn header bảo mật là các dòng máy chủ gửi kèm mỗi phản hồi để nói cho trình duyệt biết được tải tài nguyên từ đâu, được nhúng trang ở đâu và được dùng API nào. Hai thứ khác nhau về vai trò nhưng cùng nằm ở một chỗ, là cấu hình phản hồi HTTP.
Cần phân biệt ngay mức liên quan tới SEO, vì nhóm này khác nhóm accessibility ở bài trước. HTTPS là một tín hiệu xếp hạng nhẹ mà Google công bố từ năm 2014, và đó là một trong rất ít thứ thuộc bảo mật được xác nhận có ảnh hưởng. Các header như CSP, Referrer-Policy hay Permissions-Policy thì không phải tín hiệu xếp hạng.
Nhưng ảnh hưởng gián tiếp thì rất thật và rất nhanh. Mixed content dạng chủ động bị trình duyệt chặn hẳn, nên một tệp CSS hoặc JavaScript gọi qua HTTP là một phần giao diện hoặc một phần chức năng biến mất. Một website bị chiếm quyền sẽ nhận nhãn cảnh báo trong kết quả tìm kiếm và có thể bị áp thao tác thủ công, tức mất lưu lượng theo cách không sửa được bằng nội dung.
Đầu ra cần có: bảng giá trị header thật của từng nhóm URL, danh sách tài nguyên còn gọi qua HTTP, kết quả kiểm TLS, và thứ tự bật kèm cách quay lui. Nền của chuẩn nằm ở hai mục tra cứu HTTPS và SSL Standard cùng HTTPS và SSL Hardening.
2. Checklist HTTPS và header: 10 tiêu chí từ 164 đến 173
Mười tiêu chí dưới đây chia thành hai nhóm rõ rệt: ba tiêu chí bắt buộc chạm tới khả năng dùng được của website, và bảy tiêu chí còn lại là lớp gia cố. Các nhãn trọng số dùng để ưu tiên trong dự án; chúng không phải bảng yếu tố xếp hạng do Google công bố.
| Mã | Tiêu chí | Giá trị hoặc mức mong đợi | Trọng số |
|---|---|---|---|
| 164 | Không có mixed content | 0 tài nguyên gọi qua HTTP | Bắt buộc |
| 165 | TLS và chứng chỉ | TLS 1.3 ưu tiên, tối thiểu 1.2, đủ chuỗi | Bắt buộc |
| 166 | HSTS | max-age tối thiểu 31536000 | Quan trọng |
| 167 | X-Content-Type-Options | nosniff, kèm Content-Type đúng | Quan trọng |
| 168 | Chống nhúng trái phép | CSP frame-ancestors theo nhu cầu thật | Quan trọng |
| 169 | Content-Security-Policy | Allowlist nguồn, hạn chế unsafe-inline | Quan trọng |
| 170 | Referrer-Policy | strict-origin-when-cross-origin | Quan trọng |
| 171 | Permissions-Policy | Chỉ mở API tại origin thật sự cần | Nên có |
| 172 | Cookie quản trị | Secure, HttpOnly, SameSite phù hợp | Bắt buộc |
| 173 | Giảm lộ công nghệ | Không lộ phiên bản trong Server và X-Powered-By | Nên có |
Phép kiểm nền cho cả mười tiêu chí gọn hơn mọi nhóm trước, vì tất cả đều nằm trong phản hồi HTTP. Một lệnh đọc header là thấy được bảy trên mười tiêu chí:
curl -sSI https://ten-mien.com/ | sortĐiều quan trọng khi đọc kết quả: header phải được kiểm trên NHIỀU nhóm URL, không chỉ trang chủ. Trang chủ có thể đi qua cache còn trang quản trị thì không, tệp tĩnh có thể do một lớp khác phục vụ, và trang trả lỗi thường được máy chủ sinh ra ngoài đường đi thông thường nên thiếu hẳn header.
3. Tiêu chí 164: Không có mixed content
Không có mixed content nghĩa là mọi tài nguyên trên một trang HTTPS đều tải qua HTTPS, gồm script, CSS, font, iframe, ảnh, video và mọi request mà JavaScript tự gọi. Trình duyệt xử lý hai mức khác nhau: mixed content chủ động như script, CSS và iframe bị chặn hẳn, còn ảnh và media thì trình duyệt cố nâng lên HTTPS và chỉ bỏ qua khi nâng không được.
Hệ quả của mức chủ động là điều cần nói rõ với chủ website: đó không phải một cảnh báo mà là mất chức năng. Một tệp JavaScript của biểu mẫu gọi qua HTTP thì biểu mẫu không hoạt động, và không có thông báo nào cho người dùng ngoài dòng lỗi trong console.
Cách kiểm: mở Console và tab Network trong Chrome DevTools rồi lọc theo scheme http, đó là cách bắt cả những request do script tự gọi sau khi trang tải. Rà toàn website thì crawl bằng Screaming Frog và đọc báo cáo tài nguyên không an toàn. Kiểm thêm ở các trang ít ai mở: trang giỏ hàng, trang thanh toán và trang có nhúng bản đồ hoặc video.
Trên WordPress, nguồn gốc gần như luôn là URL dạng http còn nằm trong cơ sở dữ liệu sau khi chuyển sang HTTPS, cộng với các giá trị đặt cứng trong theme và trong CSS của plugin. Chỉ thị CSP upgrade-insecure-requests giúp nâng tạm thời nhưng nó che lỗi chứ không sửa dữ liệu. Điều kiện nghiệm thu: 0 request http trên mọi nhóm URL, và 0 chuỗi http trỏ về chính tên miền còn sót trong nội dung.
4. Tiêu chí 165: TLS và chứng chỉ an toàn
TLS và chứng chỉ đạt yêu cầu là chứng chỉ còn hiệu lực, khai đúng hostname đang phục vụ, gửi đủ chuỗi tin cậy, và máy chủ chỉ còn bật TLS 1.3 cùng TLS 1.2. SSL, TLS 1.0 và TLS 1.1 đã bị coi là lỗi thời, và cipher yếu phải tắt cùng lúc, vì một phiên bản mới bật kèm cipher cũ vẫn hạ được mức bảo vệ.
Cách kiểm: chạy SSL Labs cho một lượt đánh giá đầy đủ có xếp loại, hoặc dùng testssl.sh khi cần kiểm nhanh nhiều tên miền và cần kiểm cả máy chủ nội bộ. Đọc bốn phần: hạn chứng chỉ, danh sách tên trong chứng chỉ, chuỗi trung gian, và danh sách phiên bản cùng cipher đang bật.
Ba lỗi hay gặp: chứng chỉ chỉ khai tên miền không có www trong khi bản có www vẫn phục vụ, nên một nửa khách thấy cảnh báo; thiếu chứng chỉ trung gian nên máy tính có sẵn bộ nhớ đệm thì vào được còn điện thoại mới thì báo lỗi; và chứng chỉ hết hạn vì tự động gia hạn đã dừng từ nhiều tuần trước mà không ai nhận thông báo.
Vì vậy phần cần làm không phải chỉ cấu hình một lần: hãy đặt một phép kiểm hạn chứng chỉ tự động và cho nó báo trước tối thiểu hai tuần. Điều kiện nghiệm thu: chứng chỉ hợp lệ cho mọi hostname đang phục vụ, chuỗi đầy đủ, chỉ còn TLS 1.2 và 1.3, và có cảnh báo hạn tự động đang hoạt động.
5. Tiêu chí 166: HSTS Header
HSTS là header nói với trình duyệt rằng từ nay chỉ được truy cập tên miền này bằng HTTPS, và nó chỉ nên bật sau khi HTTPS đã chạy ổn định, với max-age tối thiểu 31536000 giây tức một năm. Hai chỉ thị includeSubDomains và preload chỉ thêm khi mọi subdomain đều đã phục vụ HTTPS đầy đủ.
Strict-Transport-Security: max-age=31536000; includeSubDomainsĐây là header cần cẩn thận nhất trong cả nhóm, vì nó là cam kết một chiều. Trình duyệt đã nhận HSTS sẽ từ chối kết nối HTTP tới tên miền đó trong suốt thời gian max-age, và người dùng không có cách bỏ qua. Nếu một subdomain nào đó chỉ có HTTP, thêm includeSubDomains là làm subdomain đó không vào được nữa đối với mọi người từng mở website chính.
Danh sách preload thì đi xa hơn một bước: nó nhúng tên miền vào chính trình duyệt, nên hiệu lực không phụ thuộc lần truy cập đầu tiên. Đổi lại, rút một tên miền khỏi danh sách đó mất nhiều tháng và phải chờ các bản trình duyệt mới phát hành. Cách bật an toàn là tăng dần: max-age ngắn trước, quan sát, rồi mới lên một năm, rồi mới xét includeSubDomains, và chỉ xét preload sau cùng.
Một chi tiết kỹ thuật hay bị bỏ sót: HSTS chỉ có hiệu lực khi được gửi trên phản hồi HTTPS. Đặt nó vào khối HTTP là một dòng không ai đọc. Điều kiện nghiệm thu: header có mặt trên phản hồi HTTPS của mọi nhóm URL, max-age đạt một năm, và mọi subdomain đã HTTPS trước khi thêm includeSubDomains.
6. Tiêu chí 167: X-Content-Type-Options
X-Content-Type-Options với giá trị nosniff yêu cầu trình duyệt tin vào Content-Type mà máy chủ khai, thay vì tự đoán loại tệp theo nội dung. Vì vậy tiêu chí này có hai nửa và nửa thứ hai quan trọng hơn: gửi nosniff mà khai Content-Type sai thì tài nguyên bị từ chối chứ không phải được bảo vệ.
X-Content-Type-Options: nosniffLý do cần: khi trình duyệt tự đoán, một tệp người dùng tải lên được khai là ảnh nhưng chứa mã HTML có thể bị đoán thành HTML rồi thực thi trong ngữ cảnh tên miền của website. Đó là con đường tấn công đi qua đúng chức năng tải tệp lên mà website nào cũng có.
Cách kiểm: đọc header bằng cURL hoặc SecurityHeaders.com, rồi kiểm chéo Content-Type của bốn nhóm tệp thường sai nhất: tệp CSS và JavaScript do plugin phục vụ qua PHP, tệp font, tệp tải xuống trong thư mục uploads, và tệp JSON của các endpoint tuỳ biến.
Với WordPress, chỗ hay sai là các tệp tài nguyên được nạp qua một tệp PHP thay vì phục vụ trực tiếp: khi đó Content-Type do mã PHP đặt, và nhiều plugin đặt sai hoặc không đặt. Điều kiện nghiệm thu: nosniff có trên mọi phản hồi, và Content-Type đúng cho cả bốn nhóm tệp vừa nêu.
7. Tiêu chí 168: Chống nhúng trang trái phép
Chống nhúng trái phép là việc khai rõ những website nào được đặt trang của mình trong iframe, bằng chỉ thị CSP frame-ancestors, và giữ thêm X-Frame-Options cho trình duyệt cũ nếu cần. Quyết định phải xuất phát từ nhu cầu nhúng thật, vì chặn hết là làm hỏng những chỗ đang cố ý nhúng.
Content-Security-Policy: frame-ancestors 'self'X-Frame-Options: SAMEORIGINMối nguy cần chặn là clickjacking: kẻ tấn công đặt trang của anh chị trong một iframe trong suốt, phủ lên giao diện của họ, rồi người dùng tưởng đang bấm vào nút của họ nhưng thật ra bấm vào nút trong trang mình. Chỗ đáng bảo vệ nhất vì vậy là trang đăng nhập, trang quản trị và các trang xác nhận thao tác.
Ba điều cần biết để khai đúng: frame-ancestors thắng X-Frame-Options ở các trình duyệt hiểu CSP, nên hai dòng không xung đột mà xếp thứ tự; giá trị ALLOW-FROM của X-Frame-Options đã bị bỏ và không còn tác dụng, muốn cho phép một tên miền cụ thể thì phải dùng frame-ancestors; và nếu website có nội dung được nhúng cố ý, hãy liệt kê chính xác tên miền đó thay vì mở toàn bộ.
Trước khi bật, hãy đi tìm những chỗ đang nhúng thật: trang landing của đối tác, công cụ nhúng trong nội bộ, bản xem trước trong trình biên tập, và các trang mà chính plugin mở trong iframe. Điều kiện nghiệm thu: frame-ancestors khai đúng danh sách đã xác nhận, trang đăng nhập và quản trị không nhúng được từ tên miền lạ, và các chỗ nhúng cố ý vẫn hoạt động.
8. Tiêu chí 169: Content-Security-Policy
CSP là danh sách cho phép khai rõ trang được tải script, style, ảnh, font, frame và gửi request tới những nguồn nào, và nó phải chạy ở chế độ chỉ báo cáo trước khi cưỡng chế. Đây là header khó nhất trong nhóm, vì nó là header duy nhất có thể làm website ngừng hoạt động chỉ vì khai thiếu một tên miền.
Content-Security-Policy-Report-Only: default-src 'self'; img-src 'self' data: https:; ...Trình tự triển khai nên là bốn bước, không nhảy bước: bật bản Report-Only với một chính sách chặt, thu báo cáo vi phạm trong ít nhất một tuần để đủ phủ các trang ít truy cập, bổ sung các nguồn hợp lệ đã lộ ra trong báo cáo, rồi mới đổi sang header cưỡng chế. Một tuần là con số tối thiểu vì trang thanh toán, trang cảm ơn và các biểu mẫu thường chỉ được mở vài lần mỗi ngày.
Về chất lượng chính sách: hạn chế wildcard, hạn chế unsafe-inline và unsafe-eval, vì ba thứ đó mở lại đúng lỗ mà CSP sinh ra để bịt. Cách đúng cho script nội tuyến là dùng nonce hoặc hash. CSP Evaluator của Google đọc chính sách và chỉ ra chỗ nào đang bị vô hiệu hóa bởi một giá trị quá rộng, nên hãy chạy nó trước khi cưỡng chế.
Riêng với WordPress, cần nói thẳng một giới hạn: trình biên tập khối và nhiều trang quản trị dựa nhiều vào script nội tuyến, nên một CSP chặt cho toàn bộ website thường không áp được cho khu quản trị mà không hỏng chức năng. Cách làm thực tế là đặt chính sách chặt cho phần công khai và một chính sách riêng, nới hơn, cho khu quản trị. Điều kiện nghiệm thu: chính sách công khai đã cưỡng chế, không còn wildcard ở script-src, và báo cáo vi phạm bảy ngày liên tục không còn nguồn hợp lệ nào bị chặn.
9. Tiêu chí 170: Referrer-Policy
Referrer-Policy quyết định trình duyệt gửi bao nhiêu thông tin về trang nguồn khi người dùng đi sang website khác, và mức nền hợp lý là strict-origin-when-cross-origin. Với mức đó, website khác chỉ nhận được tên miền của anh chị, còn đường dẫn và tham số truy vấn thì không ra khỏi website.
Referrer-Policy: strict-origin-when-cross-originLý do cần: đường dẫn và tham số thường mang thông tin không nên chia sẻ, ví dụ URL của một trang xem trước, một mã đơn hàng, một token trong tham số, hay đơn giản là toàn bộ hành trình đọc của người dùng. Khi rò rỉ, nó đi tới mọi tên miền mà trang có liên kết ra hoặc có tải tài nguyên từ đó.
Một điểm cần biết để không đo sai: strict-origin-when-cross-origin đã là mặc định của các trình duyệt lớn từ vài năm nay. Khai tường minh vẫn có giá trị vì nó không phụ thuộc phiên bản trình duyệt và vì nó ghi lại quyết định ở chỗ kiểm được, nhưng đừng kỳ vọng bật nó lên là thay đổi một con số nào đang đo.
Chiều ngược lại cũng cần cân nhắc: đặt mức quá chặt như no-referrer là tự tay xóa dữ liệu nguồn truy cập của chính mình trong công cụ phân tích, và cũng xóa luôn thông tin nguồn mà các website anh chị dẫn link tới sẽ thấy. Điều kiện nghiệm thu: header có mặt trên mọi nhóm URL với mức đã chọn, và không có mức chặt hơn được đặt riêng ở đâu đó làm mất dữ liệu nguồn.
10. Tiêu chí 171: Permissions-Policy
Permissions-Policy khai rõ những API nhạy cảm nào được dùng và được dùng ở đâu, gồm camera, microphone, geolocation cùng các API tương tự, và nguyên tắc là chỉ mở tại origin thật sự cần. Header này thay cho Feature-Policy cũ, nên nếu cấu hình còn dòng Feature-Policy thì đó là dấu hiệu cấu hình chưa được cập nhật.
Permissions-Policy: camera=(), microphone=(), geolocation=()Dấu ngoặc rỗng nghĩa là không cho phép ở bất kỳ đâu, kể cả chính website. Nếu một chức năng thật sự cần, ví dụ trang tìm cửa hàng gần nhất cần vị trí, hãy mở đúng chức năng đó cho chính origin bằng geolocation bằng self, và chỉ mở trên nhóm URL đó nếu hạ tầng cho phép khai theo đường dẫn.
Giá trị thực tế của header này với một website nội dung là chặn trước những gì mình không dùng. Phần lớn website WordPress không cần camera, microphone hay cảm biến, nên khai rỗng cho chúng là một dòng cấu hình không tốn gì mà loại bỏ cả một nhóm khả năng bị lạm dụng qua script của bên thứ ba.
Cần soát trước khi bật: các script nhúng của bên thứ ba đôi khi có dùng một API trong danh sách, ví dụ công cụ ghi lại phiên hoặc công cụ hỗ trợ trực tuyến có gọi microphone. Điều kiện nghiệm thu: header có mặt, mọi API không dùng được khai rỗng, và các chức năng thật sự cần vẫn hoạt động sau khi bật.
12. Tiêu chí 173: Giảm lộ công nghệ máy chủ
Giảm lộ công nghệ là việc bỏ hoặc rút gọn thông tin phiên bản trong các header như Server và X-Powered-By, cùng các header do framework tự thêm. Cần nói rõ mức giá trị của việc này: đây là gia cố, không phải một lớp bảo vệ, và nó không thay thế việc cập nhật bản vá.
Lý do vẫn nên làm: một header khai chính xác số phiên bản là một câu trả lời sẵn cho công cụ quét tự động, giúp nó ghép ngay tên miền của anh chị vào danh sách mục tiêu của một lỗ hổng vừa công bố. Bỏ số phiên bản không làm lỗ hổng biến mất, nó chỉ làm mình không còn nằm trong nhóm bị tìm thấy trước nhất.
Cách kiểm và cách sửa: đọc header bằng cURL rồi xử lý theo từng lớp. Với Nginx thì tắt hiển thị phiên bản, với Apache thì đặt mức ServerTokens về Prod và tắt dòng ký tên ở trang lỗi, với PHP thì tắt expose_php để không còn X-Powered-By. WordPress còn hai chỗ khác cùng loại: thẻ meta generator khai số phiên bản trong HTML, và tham số ver gắn vào URL của tệp CSS cùng JavaScript.
Đừng biến việc này thành mục tiêu chính. Thứ tự đúng là vá trước, gia cố sau, vì một website ẩn kỹ mà chạy phiên bản cũ vẫn bị khai thác, còn một website khai rõ phiên bản mà luôn cập nhật thì không có gì để khai thác. Điều kiện nghiệm thu: không header nào còn số phiên bản, thẻ generator đã gỡ, và có một quy trình cập nhật đang chạy thật.
13. Chuyển hướng HTTP sang HTTPS và một phiên bản chuẩn
HTTPS chỉ có tác dụng khi mọi đường vào đều dẫn tới nó, nên phần chuyển hướng là phần dễ sai nhất và cũng là phần ảnh hưởng tới SEO rõ nhất trong cả bài. Mục tiêu là mỗi URL cũ tới đích chỉ trong một bước, và toàn website chỉ phục vụ đúng một phiên bản chuẩn.
Bốn tổ hợp cần kiểm từng cái một, không suy từ nhau: http không www, http có www, https không www, https có www. Ba tổ hợp phải trả 301 về tổ hợp thứ tư trong đúng một bước. Lỗi kinh điển là chuỗi hai bước, http không www chuyển sang https không www rồi mới sang https có www, vì hai lớp cấu hình mỗi lớp làm một nửa việc.
curl -sSI http://ten-mien.com/ | grep -i "^HTTP/\|^location"Ba thứ phải khớp nhau sau khi chốt phiên bản chuẩn: đích của chuyển hướng, thẻ canonical trong HTML, và URL trong sitemap. Ba chỗ nói ba phiên bản khác nhau là tự tạo mơ hồ ngay tại chỗ vừa dọn xong. Nguyên tắc chuyển hướng chung nằm ở mục tra cứu Redirect Logic.
Một lưu ý về thứ tự với HSTS: phải hoàn tất phần chuyển hướng và xác nhận mọi subdomain đã HTTPS TRƯỚC khi bật HSTS. Bật trước là khóa luôn những đường vào chưa sửa, và lúc đó người dùng không có cách bỏ qua.
14. HTTPS trên WordPress: siteurl, plugin và CDN
Trên WordPress, HTTPS không chỉ là cấu hình máy chủ, vì WordPress tự sinh phần lớn URL trong trang từ hai giá trị lưu trong cơ sở dữ liệu là siteurl và home. Hai giá trị đó còn dạng http thì trang vẫn phát ra URL http dù máy chủ đã phục vụ HTTPS.
Ba việc theo thứ tự: đổi hai giá trị siteurl và home sang https, hoặc khai cứng bằng WP_HOME và WP_SITEURL trong wp-config.php; thay các chuỗi http trỏ về chính tên miền còn nằm trong nội dung bài và trong tuỳ chọn của theme, chú ý dữ liệu dạng chuỗi tuần tự phải thay bằng công cụ hiểu định dạng đó chứ không thay thô; và bật FORCE_SSL_ADMIN.
Khi website đứng sau proxy hoặc CDN, thêm một bước bắt buộc: cho WordPress biết kết nối gốc là HTTPS dựa trên header mà proxy gửi kèm. Thiếu bước này, WordPress thấy kết nối tới nó là HTTP nên tự chuyển hướng sang HTTPS, proxy lại chuyển về, và kết quả là vòng lặp chuyển hướng. Đây cũng là lý do chế độ mã hóa nửa đường của một số CDN, tức HTTPS tới trình duyệt nhưng HTTP tới máy chủ gốc, không nên dùng.
Về nhóm plugin bật HTTPS bằng cách viết lại đầu ra: chúng có ích để chạy được ngay, nhưng cần biết giới hạn. Chúng sửa HTML lúc phát ra, còn dữ liệu trong cơ sở dữ liệu vẫn dạng http, nên mọi đường đi không qua bộ lọc đó vẫn phát http, ví dụ nội dung trả về từ API, sitemap do một plugin khác sinh, hay email gửi từ website. Coi chúng là bước tạm, rồi sửa dữ liệu thật.
15. Đặt header ở đâu: máy chủ web, PHP hay plugin
Một header đặt sai lớp là một header không được gửi ở đúng những chỗ cần nhất, nên câu hỏi đặt ở đâu quan trọng ngang câu hỏi đặt giá trị gì. Ba lớp có thể gửi header, và phạm vi của chúng khác nhau hẳn.
Lớp máy chủ web gửi header cho MỌI phản hồi, gồm tệp tĩnh, tệp tải xuống và trang lỗi do chính máy chủ sinh ra. Lớp PHP và lớp plugin chỉ gửi được cho những phản hồi do WordPress xử lý, nên ảnh, tệp CSS và JavaScript phục vụ trực tiếp sẽ không có header nào. Vì vậy nhóm header bảo mật nên đặt ở lớp máy chủ web.
Hai bẫy khi cấu hình ở lớp máy chủ. Thứ nhất, header trùng: máy chủ gửi một dòng và plugin gửi một dòng nữa, và với một số header thì trình duyệt lấy giá trị chặt hơn, với một số khác thì hành vi khó đoán, nên hãy kiểm bằng cURL để thấy đúng số dòng thật. Thứ hai, ở Nginx thì việc khai một dòng thêm header trong một khối con sẽ hủy toàn bộ các dòng đã khai ở khối cha, nên thêm một header mới cho một đường dẫn có thể vô tình xóa hết các header khác của đường dẫn đó.
Vì vậy phép kiểm cuối cùng luôn là đọc header thật của nhiều nhóm URL: một trang nội dung, một tệp tĩnh, một URL trong khu quản trị, một URL API và một URL không tồn tại để lấy phản hồi 404. Năm nhóm đó đủ để lộ mọi chỗ cấu hình bị thiếu, và cách kiểm phản hồi theo mã trạng thái thì xem mục tra cứu HTTP Status Code Audit.
16. Quan hệ thật giữa bảo mật và SEO
Trong nhóm này chỉ có HTTPS là tín hiệu xếp hạng được Google xác nhận, còn các header bảo mật thì không, nhưng ảnh hưởng gián tiếp của cả nhóm lại lớn hơn nhiều nhóm khác. Biết ranh giới giúp giải thích được với chủ website mà không phải hứa điều Google chưa nói.
Phần được xác nhận: Google công bố năm 2014 rằng HTTPS là một tín hiệu xếp hạng nhẹ. Đó là lý do đủ để hoàn tất tiêu chí 164 và 165, nhưng nó nhẹ, nên đừng dùng nó để giải thích một biến động hạng.
Phần ảnh hưởng gián tiếp mà nặng: mixed content chủ động bị chặn, nên một tệp CSS hoặc JavaScript gọi qua HTTP là một phần trang không render được, và Google xếp hạng trang đã render. Chuỗi chuyển hướng nhiều bước làm loãng và làm chậm. Còn nghiêm trọng nhất là website bị chiếm quyền: nó dẫn tới nhãn cảnh báo trong kết quả tìm kiếm, tới thao tác thủ công, và tới nội dung rác được chèn vào chính các trang đang có hạng.
Phần không liên quan tới xếp hạng: CSP, Referrer-Policy, Permissions-Policy, nosniff và mức lộ phiên bản. Lý do làm chúng là giảm rủi ro bị chiếm quyền và bảo vệ dữ liệu người dùng, tức là phòng đúng cái hậu quả nặng vừa nói ở trên. Cách nói đúng với chủ website vì vậy là: nhóm này không mua hạng, nó bảo vệ những gì đã có. Góc nhìn rộng hơn về niềm tin nằm ở mục Security và Privacy Trust.
17. Ma trận kiểm tra theo lớp và theo nhóm URL
Ma trận dưới đây gom phép kiểm theo lớp cấu hình, vì mỗi tiêu chí trong nhóm này được quyết định ở một lớp khác nhau và sửa sai lớp là sửa không có tác dụng. Cách dùng là đi hết một lớp rồi mới sang lớp kế, và luôn kết thúc bằng một lượt đọc header thật.
| Lớp | Tiêu chí thuộc lớp | Cách kiểm |
|---|---|---|
| Chứng chỉ và TLS | 165 | SSL Labs hoặc testssl.sh |
| Máy chủ web | 166, 167, 168, 169, 170, 171, 173 | curl -sSI trên năm nhóm URL |
| Chuyển hướng | 164, 166 | Kiểm bốn tổ hợp www và scheme |
| Cơ sở dữ liệu WordPress | 164 | Tìm chuỗi http trỏ về chính tên miền |
| Nội dung và theme | 164 | Console và tab Network, crawl toàn website |
| Phiên đăng nhập | 172 | Đọc Set-Cookie và tab Application |
| PHP và plugin | 167, 173 | Kiểm Content-Type và header của tệp qua PHP |
| Bên thứ ba | 169, 171 | Báo cáo vi phạm CSP trong bảy ngày |
Năm nhóm URL cần đọc header ở mỗi lượt: một trang nội dung, một tệp tĩnh, một URL trong khu quản trị, một URL API, và một URL không tồn tại. Thiếu nhóm cuối là chỗ hay lọt nhất, vì trang lỗi thường do máy chủ sinh ra ngoài đường đi thông thường nên không nhận header nào.
18. Thứ tự triển khai để không làm website chết
Nhóm này khác mọi nhóm trước ở một điểm: hai trong mười tiêu chí có thể làm website ngừng hoạt động nếu bật sai, nên thứ tự triển khai quan trọng ngang giá trị cấu hình. Hai tiêu chí đó là CSP và HSTS, và cả hai đều phải ở cuối.
Nhóm một, làm trước và không có rủi ro: dọn mixed content, sửa chứng chỉ và TLS, dọn chuyển hướng về một phiên bản chuẩn, bảo vệ cookie quản trị. Bốn việc này đều là sửa cái đang sai, nên không có chiều quay lui cần lo.
Nhóm hai, thêm được ngay và rủi ro thấp: nosniff, Referrer-Policy, Permissions-Policy, giảm lộ phiên bản. Rủi ro duy nhất là Permissions-Policy chặn một API mà một script bên thứ ba đang dùng, và điều đó phát hiện được trong vài phút bằng một lượt bấm thử.
Nhóm ba, bật sau cùng và bật theo bước: chống nhúng thì phải rà danh sách nhúng hợp lệ trước; CSP thì Report-Only trong ít nhất bảy ngày rồi mới cưỡng chế; HSTS thì max-age ngắn trước, lên một năm sau, includeSubDomains chỉ khi mọi subdomain đã HTTPS, và preload chỉ khi chấp nhận mất nhiều tháng nếu muốn rút lại.
Với mỗi thay đổi ở nhóm ba, hãy ghi sẵn cách quay lui trước khi bật, và bật vào giờ thấp điểm có người trực. Đó không phải thủ tục hình thức: hai header này không hỏng ngay lúc bật mà hỏng ở trang mà lúc bật không ai mở.
19. Công cụ Novaverb, tài liệu gốc và hướng thực hành
Với nhóm HTTPS và header, công cụ tự động đọc được gần hết, nên hãy dùng chúng để lấy bản gốc rồi chỉ kiểm tay ở phần quyết định là danh sách nguồn của CSP và danh sách nhúng hợp lệ. Mỗi công cụ có phạm vi riêng, cần đọc đúng phạm vi trước khi kết luận.
- Website Security Checker của Novaverb: rà nhanh HTTPS, chứng chỉ và bộ header bảo mật của một URL, dùng để lấy ảnh chụp trạng thái trước khi sửa.
- PageSpeed Checker của Novaverb: chạy Lighthouse, dùng để bắt phần mixed content và các tài nguyên bị chặn hiện ra thành lỗi tải.
- SSL Labs và testssl.sh: kiểm sâu phiên bản TLS, cipher và chuỗi chứng chỉ, tức phần mà công cụ đọc header không thấy.
- CSP Evaluator: đọc chính sách CSP và chỉ ra chỗ đang bị vô hiệu hóa bởi một giá trị quá rộng, chạy trước khi cưỡng chế.
- cURL: phép kiểm cuối cùng và đáng tin nhất, vì nó cho thấy đúng những dòng máy chủ gửi ra, kể cả header trùng.
Tài liệu nên giữ trong hồ sơ dự án: MDN về Content-Security-Policy, MDN về Strict-Transport-Security, OWASP HTTP Headers Cheat Sheet và công bố năm 2014 của Google về HTTPS. Dùng tài liệu gốc để phân biệt quy định, khuyến nghị và quy ước nội bộ.
Nếu đang tìm lộ trình đào tạo SEO, có thể dùng checklist này làm bài thực hành: đọc header của năm nhóm URL, ghi bằng chứng, sửa theo thứ tự ba nhóm rồi nghiệm thu lại. Trang khóa học SEO giúp đối chiếu chương trình theo nền tảng hiện tại.
Muốn đưa audit HTTPS và header vào quy trình SEO trên website thật, anh chị có thể xem phạm vi và cách học của khóa học SEO Master. Giá trị của bài thực hành nằm ở khả năng giải thích lỗi và chứng minh đã sửa bằng cùng một phép kiểm.
Kết hợp bài này với cache và kết nối cùng accessibility: ba bài đều đo trên phản hồi thật của máy chủ chứ không đo trên mã nguồn.
20. Câu hỏi thường gặp và kết luận
Các câu trả lời dưới đây giúp phân biệt tiêu chuẩn bảo mật, khuyến nghị gia cố và bằng chứng nghiệm thu trong WordPress. Khi gặp một kết quả không rõ, hãy quay về lớp cấu hình cụ thể và nhóm URL cụ thể để chọn phép kiểm phù hợp trước khi đổi cấu hình máy chủ hoặc cài thêm plugin.
HTTPS có phải yếu tố xếp hạng không?
Có, HTTPS là một yếu tố xếp hạng, nhưng là tín hiệu nhẹ, và Google công bố điều đó từ năm 2014. Đây là một trong rất ít thứ thuộc bảo mật được xác nhận có ảnh hưởng tới xếp hạng. Phần tác động thật lớn hơn nằm ở chiều gián tiếp: mixed content làm tài nguyên bị chặn, và website bị chiếm quyền thì mất lưu lượng theo cách nội dung không cứu được.
Header bảo mật có giúp tăng hạng không?
Không. CSP, Referrer-Policy, Permissions-Policy và nosniff không phải tín hiệu xếp hạng. Lý do làm chúng là giảm rủi ro bị chiếm quyền và bảo vệ dữ liệu người dùng, tức phòng đúng cái hậu quả nặng nhất, chứ không phải để đổi lấy vị trí.
Có nên bật HSTS preload ngay không?
Không nên bật ngay. Preload nhúng tên miền vào chính trình duyệt nên hiệu lực không phụ thuộc lần truy cập đầu, nhưng rút ra mất nhiều tháng. Hãy đi theo bước: max-age ngắn, rồi một năm, rồi includeSubDomains khi mọi subdomain đã HTTPS, preload sau cùng.
CSP làm website hỏng thì xử lý thế nào?
Đó là lý do phải chạy Content-Security-Policy-Report-Only trước. Bản chỉ báo cáo không chặn gì, chỉ ghi lại vi phạm, nên anh chị thấy đủ danh sách nguồn hợp lệ trong ít nhất bảy ngày rồi mới đổi sang header cưỡng chế.
Plugin bật HTTPS có đủ không?
Chỉ đủ để chạy được ngay. Nhóm plugin đó viết lại HTML lúc phát ra, còn URL trong cơ sở dữ liệu vẫn dạng http, nên mọi đường không qua bộ lọc vẫn phát http: nội dung từ API, sitemap của plugin khác, email gửi từ website. Hãy sửa dữ liệu thật rồi mới bỏ plugin.
Nên đặt header ở plugin hay ở máy chủ?
Ở máy chủ web. Lớp đó gửi header cho mọi phản hồi, gồm tệp tĩnh, tệp tải xuống và trang lỗi do máy chủ sinh ra. Plugin chỉ gửi được cho phản hồi mà WordPress xử lý, nên ảnh và tệp CSS phục vụ trực tiếp sẽ không có header nào.
Ẩn phiên bản máy chủ có làm website an toàn hơn không?
Không đáng kể, và đừng coi đó là mục tiêu. Ẩn phiên bản chỉ làm website không nằm trong nhóm bị công cụ quét tự động tìm thấy trước nhất. Lỗ hổng vẫn còn nguyên nếu chưa vá, nên thứ tự đúng là vá trước, gia cố sau.
Làm sao biết header đã tới mọi trang?
Đọc header thật của năm nhóm URL: một trang nội dung, một tệp tĩnh, một URL khu quản trị, một URL API và một URL không tồn tại. Nhóm cuối hay lọt nhất. Dùng cURL chứ đừng suy từ cấu hình, vì một khối con có thể vô tình hủy các header đã khai ở khối cha.
Kết luận: nhóm HTTPS và header không mua thêm hạng cho website, nó bảo vệ những gì website đã có. Kiểm đủ mười tiêu chí 164-173 trên năm nhóm URL, sửa theo ba nhóm ưu tiên và để CSP cùng HSTS ở cuối cùng giúp SEO WordPress có một quy trình cải thiện rõ ràng mà không làm website chết giữa đường.