Lỗi mixed content: Cách kiểm tra và khắc phục

Lỗi mixed content xuất hiện khi một trang được tải qua HTTPS nhưng vẫn gọi một hoặc nhiều tài nguyên bằng HTTP. Tài nguyên còn sót có thể là ảnh, tệp CSS, JavaScript, font, iframe, API hoặc nội dung được nhúng từ bên thứ ba.

Trình duyệt có thể tự nâng cấp, cảnh báo hoặc chặn các yêu cầu này tùy loại tài nguyên và phiên bản trình duyệt. Vì vậy, một trang nhìn có vẻ bình thường vẫn có thể tồn tại lỗi cần xử lý.

Mixed content là gì?

Mixed content, hay nội dung hỗn hợp, là tình trạng tài liệu HTML chính sử dụng kết nối HTTPS nhưng một phần nội dung bên trong lại được yêu cầu qua HTTP không mã hóa.

Có thể chia tài nguyên hỗn hợp thành hai nhóm chính:

• Tài nguyên có khả năng tác động trực tiếp đến trang: JavaScript, CSS, iframe, yêu cầu API, web worker hoặc kết nối WebSocket. Đây là nhóm rủi ro cao và thường bị trình duyệt chặn.
• Tài nguyên hiển thị: ảnh, âm thanh hoặc video. Một số trình duyệt có thể tự chuyển yêu cầu sang HTTPS, nhưng hành vi không giống nhau trong mọi trường hợp.

Font thường được tải từ CSS và có thể bị chặn nếu URL nguồn vẫn dùng HTTP. Kết quả là trang hiển thị sai kiểu chữ dù thanh địa chỉ không luôn cho biết rõ nguyên nhân.

Mixed content không đồng nghĩa với chứng chỉ SSL hết hạn hoặc cấu hình chứng chỉ sai. Đây là các vấn đề khác nhau và cần được kiểm tra riêng.

Vì sao website HTTPS vẫn báo không bảo mật?

Việc cài chứng chỉ và chuyển URL trang sang HTTPS chưa bảo đảm toàn bộ website đã an toàn. Cảnh báo vẫn có thể xuất hiện do:

• Nội dung cũ trong cơ sở dữ liệu còn chứa đường dẫn HTTP.
• Giao diện hoặc tiện ích mở rộng gọi ảnh, CSS hay JavaScript bằng URL cố định.
• Tệp CSS chứa ảnh nền hoặc font sử dụng HTTP.
• Mã JavaScript tạo yêu cầu HTTP sau khi trang đã tải.
• Iframe, video, biểu mẫu hoặc tiện ích bên thứ ba chưa hỗ trợ HTTPS.
• Phiên bản ảnh responsive trong srcset chưa được cập nhật.
• Bộ nhớ đệm của website, CDN hoặc trình duyệt vẫn lưu phiên bản cũ.
• Chuyển hướng sang HTTPS có tồn tại nhưng tài nguyên đích không hỗ trợ HTTPS đầy đủ.

Cũng cần phân biệt cảnh báo mixed content với lỗi chứng chỉ, tên miền không khớp chứng chỉ hoặc chứng chỉ đã hết hạn. Nếu Console không ghi nhận yêu cầu HTTP, hãy kiểm tra thông tin chứng chỉ và chuỗi chuyển hướng trước khi kết luận.

Cách kiểm tra mixed content bằng trình duyệt

Công cụ dành cho nhà phát triển tích hợp trong trình duyệt thường là cách nhanh nhất để xác định URL gây lỗi và tệp nào đã gọi URL đó.

1. Mở đúng trang đang có cảnh báo

Không nên chỉ kiểm tra trang chủ. Hãy mở từng loại trang đại diện, chẳng hạn:

• Trang danh mục.
• Trang bài viết.
• Trang sản phẩm hoặc dịch vụ.
• Landing page.
• Trang có biểu mẫu, video, bản đồ hoặc tiện ích nhúng.
• Trang dành cho người dùng đã đăng nhập, nếu có.

Một URL có thể không lỗi trong khi trang khác vẫn dùng mẫu giao diện hoặc trường dữ liệu cũ.

2. Kiểm tra trong Console

Mở công cụ dành cho nhà phát triển, chọn tab Console, sau đó tải lại trang. Nếu có mixed content, thông báo thường cho biết:

• URL HTTPS của trang đang mở.
• URL HTTP của tài nguyên được yêu cầu.
• Tài nguyên đã bị chặn, tự nâng cấp hay chỉ bị cảnh báo.
• Loại tài nguyên liên quan.

Hãy ghi lại cả URL tài nguyên và trang phát sinh lỗi. Chỉ có URL tài nguyên là chưa đủ để tìm nơi cần sửa, đặc biệt khi cùng một tệp được gọi từ nhiều mẫu trang.

3. Xác định nguồn gọi trong Network

Chuyển sang tab Network, tắt bộ nhớ đệm trong thời gian kiểm tra và tải lại trang. Sau đó:

1. Lọc hoặc sắp xếp các yêu cầu theo giao thức.
2. Mở yêu cầu đáng ngờ để xem URL đầy đủ.
3. Kiểm tra trường chỉ ra nguồn khởi tạo yêu cầu.
4. Xác định yêu cầu đến từ HTML, CSS, JavaScript hay iframe.
5. Kiểm tra chuỗi chuyển hướng và URL cuối cùng.

Nguồn khởi tạo rất quan trọng. Ví dụ, ảnh có thể không xuất hiện trực tiếp trong HTML mà được tạo bởi JavaScript hoặc khai báo trong một tệp CSS.

4. Tìm chuỗi HTTP trong mã nguồn và DOM

Dùng chức năng tìm kiếm trong mã nguồn trang, DOM đã dựng và các tệp CSS hoặc JavaScript để tìm chuỗi http:. Cần kiểm tra cả hai lớp:

• Mã nguồn ban đầu: phản ánh HTML do máy chủ trả về.
• DOM sau khi chạy JavaScript: phản ánh nội dung được tạo hoặc thay đổi trên trình duyệt.

Nếu chỉ xem mã nguồn ban đầu, bạn có thể bỏ sót tài nguyên do JavaScript chèn sau khi trang tải.

5. Kiểm tra trong cửa sổ riêng tư

Sau khi xác định lỗi, hãy mở trang trong cửa sổ riêng tư hoặc xóa bộ nhớ đệm rồi thử lại. Bước này giúp phân biệt tài nguyên cũ trong cache với lỗi còn tồn tại trên máy chủ.

Tìm tài nguyên HTTP bằng công cụ thu thập dữ liệu

Kiểm tra thủ công phù hợp với một vài URL, nhưng website lớn cần được thu thập dữ liệu để tìm lỗi trên nhiều mẫu trang.

Khi cấu hình công cụ thu thập dữ liệu đang dùng, nên bật các khả năng sau nếu hệ thống hỗ trợ:

• Thu thập tài nguyên ảnh, CSS, JavaScript và font.
• Kết xuất JavaScript đối với website tạo nội dung phía trình duyệt.
• Ghi lại URL nguồn và URL tài nguyên được gọi.
• Theo dõi chuyển hướng để biết URL HTTP có thực sự chuyển sang HTTPS hay không.
• Xuất danh sách tài nguyên theo giao thức và loại tệp.

Quy trình rà soát nên thực hiện như sau:

1. Thu thập toàn bộ URL có thể truy cập nội bộ.
2. Lọc các tài nguyên bắt đầu bằng giao thức HTTP.
3. Nhóm kết quả theo ảnh, CSS, JavaScript, font, iframe và yêu cầu khác.
4. Nhóm tiếp theo mẫu trang hoặc nguồn khởi tạo.
5. Ưu tiên lỗi xuất hiện trên giao diện dùng chung vì một lần sửa có thể xử lý nhiều URL.
6. Thu thập lại sau khi triển khai để so sánh kết quả.

Nếu cần đánh giá khả năng thu thập tài nguyên, kết xuất JavaScript và xuất báo cáo kỹ thuật, các tiêu chí chọn phần mềm SEO web nên được xem xét dựa trên cấu trúc thực tế của website thay vì chỉ dựa vào số lượng tính năng.

Công cụ thu thập dữ liệu không phải lúc nào cũng phát hiện tài nguyên chỉ xuất hiện sau thao tác của người dùng, như mở hộp thoại, gửi biểu mẫu hoặc cuộn đến một khu vực tải lười. Những trường hợp này vẫn cần kiểm tra trực tiếp bằng trình duyệt.

Cách sửa mixed content theo từng loại tài nguyên

Nguyên tắc chung là thay nguồn HTTP bằng nguồn HTTPS hoạt động thực sự. Không nên thay giao thức hàng loạt trước khi xác nhận máy chủ đích hỗ trợ HTTPS, chứng chỉ hợp lệ và nội dung trả về đúng.

Ảnh

Kiểm tra tất cả vị trí có thể chứa URL ảnh:

• Thuộc tính src của thẻ ảnh.
• Danh sách srcset và thẻ source trong ảnh responsive.
• Ảnh nền trong CSS hoặc thuộc tính style nội tuyến.
• Ảnh do JavaScript tải động.
• Ảnh trong nội dung cũ của hệ quản trị.
• Ảnh từ CDN hoặc máy chủ lưu trữ bên ngoài.

Với ảnh thuộc cùng tên miền, có thể dùng đường dẫn tương đối phù hợp để tránh cố định giao thức. Với ảnh bên ngoài, cần xác nhận địa chỉ HTTPS tồn tại và trả về đúng tệp.

Nếu ảnh vẫn không hiển thị sau khi đổi giao thức, hãy kiểm tra mã phản hồi, đường dẫn tệp, quyền truy cập và định dạng theo quy trình kiểm tra và sửa ảnh bị lỗi. Chuyển từ HTTP sang HTTPS không thể khắc phục một tệp đã bị xóa hoặc URL sai.

CSS

CSS có thể gây mixed content ở hai vị trí:

• Tệp CSS được gọi qua HTTP trong thẻ link.
• Tài nguyên bên trong CSS sử dụng HTTP, chẳng hạn ảnh nền, font hoặc tệp CSS được nhập tiếp.

Cần kiểm tra cả tệp CSS gốc, tệp đã gộp hoặc rút gọn và phiên bản đang được cache. Nếu hệ thống tự sinh CSS, hãy sửa cấu hình nguồn rồi tạo lại tệp thay vì chỉ chỉnh bản đã biên dịch.

Sau khi cập nhật, xóa cache ứng dụng, cache máy chủ và CDN nếu có. Nếu không, trình duyệt vẫn có thể nhận tệp CSS cũ chứa đường dẫn HTTP.

JavaScript

JavaScript có thể gọi tài nguyên không an toàn thông qua:

• Thuộc tính src của thẻ script.
• Lệnh tải module hoặc script động.
• Yêu cầu API được viết cố định bằng HTTP.
• Nội dung HTML được tạo bằng chuỗi URL cũ.
• Web worker hoặc tài nguyên tải sau tương tác.
• Kết nối WebSocket không mã hóa.

Khi đổi endpoint sang HTTPS, cần kiểm tra thêm chính sách CORS, xác thực, cookie và dữ liệu phản hồi. URL mới có thể mở được trực tiếp nhưng vẫn thất bại khi được gọi từ website do cấu hình quyền truy cập khác nhau.

Với WebSocket, kết nối dùng trên trang HTTPS cần sử dụng giao thức bảo mật tương ứng và máy chủ phải được cấu hình hỗ trợ.

Font

Font thường được khai báo trong @font-face hoặc tải trước trong phần đầu tài liệu. Để sửa lỗi:

1. Đổi URL tệp font sang HTTPS.
2. Xác nhận tệp tồn tại và máy chủ trả về đúng loại nội dung.
3. Kiểm tra CORS nếu font được tải từ tên miền khác.
4. Đảm bảo khai báo tải trước trùng với font thực tế.
5. Xóa cache CSS và CDN sau khi cập nhật.

Nếu nhà cung cấp font không hỗ trợ HTTPS, chỉ nên chuyển sang nguồn khác hoặc tự lưu trữ khi điều khoản sử dụng cho phép.

Iframe và tài nguyên bên thứ ba

Iframe, video, bản đồ, công cụ đo lường, tiện ích trò chuyện và biểu mẫu nhúng có thể là nguồn mixed content khó sửa nhất vì website không kiểm soát máy chủ đích.

Cách xử lý theo thứ tự ưu tiên:

• Dùng endpoint HTTPS chính thức của dịch vụ.
• Cập nhật đoạn mã nhúng lên phiên bản hiện hành.
• Kiểm tra toàn bộ tài nguyên con mà iframe hoặc script tiếp tục tải.
• Cập nhật cấu hình kiểm tra tính toàn vẹn nếu nội dung tệp đã thay đổi.
• Gỡ bỏ hoặc thay thế tích hợp nếu nguồn không hỗ trợ HTTPS ổn định.

Không nên cho rằng thêm chữ s vào địa chỉ là đủ. Máy chủ bên thứ ba có thể không hỗ trợ HTTPS, dùng chứng chỉ không hợp lệ hoặc trả về nội dung khác.

Biểu mẫu và điểm nhận dữ liệu

Biểu mẫu gửi dữ liệu đến địa chỉ HTTP không phải lúc nào cũng được báo dưới cùng một dạng với mixed content, nhưng vẫn là vấn đề bảo mật nghiêm trọng. Hãy kiểm tra thuộc tính gửi biểu mẫu, endpoint API và trang chuyển hướng sau khi gửi để bảo đảm toàn bộ luồng dùng HTTPS.

Xử lý nguyên nhân ở cấp hệ thống

Nếu cùng một URL HTTP xuất hiện trên nhiều trang, không nên sửa thủ công từng trang. Hãy tìm nguồn phát sinh chung:

• Cấu hình địa chỉ website trong hệ quản trị.
• Mẫu giao diện, header hoặc footer.
• Tiện ích mở rộng.
• Trường tùy chỉnh hoặc nội dung lưu trong cơ sở dữ liệu.
• Trình tạo trang và khối nội dung tái sử dụng.
• Cấu hình CDN.
• Tệp CSS hoặc JavaScript được sinh tự động.

Trước khi thay thế trong cơ sở dữ liệu, cần sao lưu và xác định hệ thống có lưu dữ liệu tuần tự hóa hay không. Thay chuỗi trực tiếp sai cách có thể làm hỏng cấu trúc dữ liệu.

Chuyển hướng HTTP sang HTTPS vẫn cần thiết, nhưng không nên xem chuyển hướng là cách sửa cuối cùng cho tài nguyên nhúng. Việc gọi trực tiếp URL HTTPS giúp giảm một lượt yêu cầu, hạn chế phụ thuộc vào chuyển hướng và cho kết quả kiểm tra rõ ràng hơn.

Chính sách bảo mật nội dung có thể hỗ trợ nâng cấp một số yêu cầu không an toàn, nhưng đây chỉ nên là lớp bảo vệ bổ sung. Nếu máy chủ đích không hỗ trợ HTTPS, yêu cầu sau khi nâng cấp vẫn thất bại. Chính sách này cũng không thay thế việc sửa URL tại nguồn.

Kiểm tra lại website sau khi cập nhật

Sau khi sửa tài nguyên HTTP, hãy thực hiện kiểm tra theo trình tự sau:

Kiểm tra trên trình duyệt

• Xóa cache hoặc dùng cửa sổ riêng tư.
• Tải lại trang với tab Console và Network đang mở.
• Xác nhận không còn cảnh báo mixed content.
• Kiểm tra không còn yêu cầu tài nguyên qua HTTP.
• Quan sát giao diện để phát hiện CSS, font hoặc ảnh bị mất.
• Thử các chức năng phụ thuộc JavaScript, API và biểu mẫu.
• Kiểm tra trên cả thiết bị di động và máy tính nếu giao diện tải tài nguyên khác nhau.

Thu thập lại toàn website

Chạy lại cùng một cấu hình thu thập dữ liệu đã dùng trước khi sửa. So sánh danh sách URL HTTP, số mẫu trang bị ảnh hưởng và nguồn khởi tạo. Việc dùng cùng cấu hình giúp tránh kết luận sai do thay đổi phạm vi thu thập.

Kiểm tra các trạng thái động

Thử những nội dung chỉ xuất hiện khi:

• Cuộn trang để kích hoạt tải lười.
• Mở menu, hộp thoại hoặc tab nội dung.
• Phát video.
• Gửi biểu mẫu.
• Đăng nhập.
• Thêm sản phẩm hoặc thực hiện bước tương tác tương tự.

Theo dõi sau triển khai

Mixed content có thể quay lại khi biên tập viên dán nội dung cũ, thay giao diện hoặc thêm tiện ích bên thứ ba. Vì vậy, nên đưa việc lọc URL HTTP vào quy trình kiểm tra định kỳ và kiểm tra trước khi phát hành thay đổi lớn.

Nếu CSS hoặc JavaScript quan trọng từng bị chặn, hãy kiểm tra thêm khả năng kết xuất và lập chỉ mục. Khi trang vẫn không xuất hiện trên kết quả tìm kiếm sau khi đã sửa, quy trình kiểm tra website không được index sẽ giúp tách mixed content khỏi các nguyên nhân như chỉ thị lập chỉ mục, robots hoặc canonical.

Câu hỏi thường gặp về lỗi mixed content

Đổi toàn bộ HTTP thành HTTPS có an toàn không?

Không nên thay hàng loạt khi chưa kiểm tra nguồn đích. Một số máy chủ không hỗ trợ HTTPS hoặc trả về nội dung khác. Cần sao lưu, thử trên môi trường phù hợp và xác nhận từng nhóm tài nguyên trước khi triển khai rộng.

Có thể chỉ dựa vào biểu tượng ổ khóa không?

Không. Trình duyệt có thể tự nâng cấp hoặc chặn tài nguyên, khiến biểu tượng trên thanh địa chỉ không phản ánh đầy đủ mọi vấn đề. Console, Network và báo cáo thu thập dữ liệu cung cấp thông tin chi tiết hơn.

Chuyển hướng HTTP sang HTTPS đã đủ chưa?

Chưa. Chuyển hướng giúp yêu cầu đi đến URL an toàn nhưng tài liệu ban đầu vẫn gọi HTTP. Nên cập nhật liên kết tại nguồn để gọi trực tiếp HTTPS.

Mixed content có làm website mất index không?

Không thể kết luận rằng mixed content tự động khiến website mất index. Tuy nhiên, nếu CSS hoặc JavaScript quan trọng bị chặn, công cụ tìm kiếm và người dùng có thể nhận được phiên bản trang không đầy đủ. Mức ảnh hưởng phụ thuộc vào tài nguyên bị chặn và vai trò của tài nguyên đó trên trang.