10 mối đe dọa hàng đầu trong Ứng dụng web của OWASP

Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về Apigee X. thông tin

Tài liệu này mô tả nhiều phương pháp mà bạn có thể dùng trong Apigee để xử lý các lỗ hổng bảo mật do OWASP xác định. Để biết thêm các phương pháp khác được ghi nhận cho Apigee, hãy tham khảo bài viết Các phương pháp giảm thiểu OWASP hàng đầu 10 năm 2021 trên Google Cloud.

Tổng quan

Các hệ sinh thái API trải qua nhiều cuộc tấn công từ cả ứng dụng bên ngoài và ứng dụng nội bộ. Việc cung cấp và sử dụng API mang lại cơ hội to lớn cho các nhà cung cấp dịch vụ, nhưng cũng tiềm ẩn một số rủi ro bảo mật. Nhà phát triển phải nhận thức được những thách thức này và giải quyết chúng khi tạo và sử dụng API.

OWASP là một cộng đồng mở chuyên giúp các tổ chức phát triển, mua và duy trì các ứng dụng cũng như API đáng tin cậy. Thông qua dự án OWASP API Security, OWASP phát hành những rủi ro bảo mật nghiêm trọng nhất đối với các ứng dụng web và API REST, đồng thời đưa ra nội dung đề xuất để giải quyết những rủi ro đó.

Nhờ Apigee, lớp proxy API có thể phát hiện, chặn và báo cáo các yêu cầu API không đúng định dạng của ứng dụng trước khi các yêu cầu đó được xử lý trên các hệ thống phụ trợ, nhờ đó giảm thiểu rủi ro và bảo vệ các dịch vụ của bạn. Các yêu cầu không đúng định dạng có thể bao gồm bất kỳ thành phần nào tạo nên giao thức cấp ứng dụng HTTP:

  • URL
  • Tiêu đề
  • Đường dẫn
  • Dung lượng

Các yêu cầu API không đúng định dạng có thể là từ ứng dụng đã biết hoặc không xác định do nhà phát triển bên ngoài, nhà phát triển nội bộ hoặc bot độc hại phát triển. Những loại yêu cầu này chiếm phần lớn các mối đe doạ OWASP, nhưng vẫn có các thành phần bổ sung của lớp proxy API cơ bản có thể giảm thiểu rủi ro, chẳng hạn như che giấu dữ liệu, ghi nhật ký, quản trị, v.v.

Nền tảng quản lý API thông minh của Apigee giúp bạn xử lý liền mạch các lỗ hổng bảo mật hàng đầu của API OWASP khi áp dụng phương pháp tập trung vào tiêu dùng để thiết kế API và kết nối chúng với các hệ thống phụ trợ. Sau đây là danh sách các chính sách/cấu hình mà Apigee đề xuất cho các mối đe doạ hàng đầu từ dịch vụ REST OWASP.

Các giải pháp Apigee thuộc nhóm 10 giải pháp hàng đầu của OWASP trong năm 2017

Có nhiều mối lo ngại về bảo mật liên quan đến việc xây dựng và bảo mật các ứng dụng web. OWASP đã phát hành danh sách 10 mối đe doạ bảo mật hàng đầu năm 2017 của OWASP cho ứng dụng web. Mặc dù ứng dụng web có nhiều phần, nhưng hầu hết các ứng dụng web hiện đại đều phụ thuộc chủ yếu vào API REST. Apigee không nhằm xử lý tất cả các nhu cầu bảo mật của ứng dụng web, nhưng có thể đóng vai trò quan trọng trong việc bảo mật các API REST. Sau đây là các mối đe doạ bảo mật hàng đầu của OWASP, kèm theo nội dung mô tả về cách bạn có thể dùng Apigee để giải quyết các mối đe doạ đó.

A1:2017 - Chèn

Để ngăn chặn tình trạng chèn dữ liệu không đáng tin cậy như SQL, NoSQL, LDAP và JavaScript (có thể dẫn đến việc thực thi các lệnh ngoài ý muốn hoặc truy cập trái phép vào dữ liệu), Apigee cung cấp một số chính sách xác thực dữ liệu đầu vào để xác minh rằng các giá trị mà ứng dụng cung cấp khớp với kỳ vọng trước khi cho phép xử lý thêm. Apigee Edge đóng vai trò là máy chủ đối với các yêu cầu API được gửi đến sẽ kiểm tra để đảm bảo rằng cấu trúc tải trọng nằm trong phạm vi chấp nhận được, còn gọi là kiểm tra giới hạn. Bạn có thể định cấu hình proxy API để quy trình xác thực dữ liệu đầu vào biến đổi dữ liệu đầu vào nhằm xoá các chuỗi ký tự rủi ro và thay thế bằng các giá trị an toàn.

Có một số phương pháp để xác thực dữ liệu đầu vào bằng nền tảng Apigee:

Xác thực loại nội dung:

A2:2017 – Xác thực bị lỗi và quản lý phiên

Những kẻ tấn công có thể truy cập mật khẩu, mã thông báo phiên và khoá để mạo danh người dùng khác bằng cách tận dụng các lỗi triển khai trong các ứng dụng. Đây không phải là vấn đề về sản phẩm chứ không phải vấn đề về việc triển khai. Apigee cung cấp các chính sách VerifyApiKey, OAuth và mã thông báo web JSON (JWT) để giúp chống lại lỗ hổng bảo mật này.

Xác thực khoá API

Xác thực khoá API là hình thức bảo mật dựa trên ứng dụng đơn giản nhất có thể được định cấu hình cho một API. Một ứng dụng khách chỉ cần đưa ra một khoá API kèm theo yêu cầu của mình, sau đó, Apigee Edge (thông qua một chính sách đi kèm proxy API) sẽ kiểm tra để đảm bảo rằng khoá API đang ở trạng thái được phê duyệt của tài nguyên đang được yêu cầu.

Apigee hỗ trợ việc tạo và xác thực Khoá API. Apigee sẽ tạo khoá và khoá bí mật API khi một ứng dụng dành cho nhà phát triển được tạo và phê duyệt có liên kết với một hoặc nhiều sản phẩm API.

Đôi khi, thuật ngữ “Khoá API” có thể mang nhiều ý nghĩa. Trong Apigee, khi mối quan hệ giữa ứng dụng và sản phẩm được hình thành, Apigee sẽ tạo một mã ứng dụng khách và mật khẩu ứng dụng khách. Một số gọi cả mã nhận dạng và bí mật là khoá API. Một số ứng dụng chỉ coi ID ứng dụng khách là khoá API. Trong giao diện người dùng Edge, bạn sẽ thấy "khoá người tiêu dùng" và "thông tin bí mật của người tiêu dùng".

Trong chính sáchVerifyAPIKey, chỉ mã ứng dụng khách hoặc "khoá người tiêu dùng" được xác minh. Nhà phát triển sẽ nhận được khoá dành cho người dùng khi họ đăng ký ứng dụng bằng Apigee và liên kết ứng dụng đó với một sản phẩm API. Nhà phát triển đưa khoá của người dùng vào các lệnh gọi mà ứng dụng gửi đến các proxy API đi kèm trong sản phẩm API.

Apigee cũng hỗ trợ khả năng nhập khoá API hiện có từ các nguồn bên ngoài.

Đối với các loại cấp quyền sử dụng OAuth, cả mã ứng dụng khách và mã bí mật đều được sử dụng.

OAuth 2.0

Khung uỷ quyền OAuth 2.0 cho phép một ứng dụng bên thứ ba được cấp quyền truy cập hạn chế vào một dịch vụ HTTP thay mặt cho chủ sở hữu tài nguyên bằng cách sắp xếp một hoạt động tương tác phê duyệt giữa chủ sở hữu tài nguyên và dịch vụ HTTP, hoặc bằng cách cho phép ứng dụng bên thứ ba tự giành quyền truy cập.

Các chính sách OAuth 2.0 của Apigee cho phép bạn triển khai và tuỳ chỉnh 4 loại cấp quyền truy cập OAuth 2.0. Bạn có thể thực thi mã truy cập OAuth bằng cách sử dụng chính sách OAuthv2. Người tiêu dùng phải được đăng ký và có một ứng dụng được phê duyệt để cấp cho họ quyền truy cập vào API. Đổi lại, họ sẽ nhận được một mã ứng dụng khách API và mật khẩu ứng dụng khách. Ứng dụng tiêu dùng phải trải qua một trong các lần cấp OAuth để được xác thực, cấp cho họ một mã truy cập mờ. Bạn có thể dùng mã thông báo này để kiểm soát quyền truy cập vào API.

Nhật Bản

Mã thông báo web JSON, hay JWT, thường được dùng để chia sẻ thông báo xác nhận quyền sở hữu hoặc câu nhận định giữa các ứng dụng được kết nối. Apigee cung cấp dịch vụ hỗ trợ JWT thông qua 3 chính sách.

  • Mã thông báo GenerateJWT (hỗ trợ chữ ký HS256 và RS256)
  • Mã thông báo ValidationJWT
  • Giải mã mã thông báo JWT mà không xác thực

A3:2017 – Tiết lộ dữ liệu nhạy cảm

Kẻ tấn công nhắm đến dữ liệu nhạy cảm như chi tiết thẻ tín dụng, số an sinh xã hội, thông tin đăng nhập, thông tin nhận dạng cá nhân (PII) và mã số thuế để thực hiện hành vi trộm cắp danh tính, ăn cắp tiền, lừa đảo và các hành vi phạm tội khác. Các ứng dụng web cần triển khai tính năng mã hoá cả khi lưu trữ và truyền tải, cũng như các chiến lược khác để đảm bảo bảo vệ dữ liệu nhạy cảm.

TLS (Bảo mật tầng truyền tải, tiền thân là SSL) là công nghệ bảo mật tiêu chuẩn để thiết lập đường liên kết được mã hoá giữa máy chủ web và ứng dụng web, chẳng hạn như trình duyệt hoặc ứng dụng. Apigee hỗ trợ cả TLS một chiều và hai chiều.

TLS hướng Bắc (ứng dụng kết nối với API đóng vai trò là máy chủ) được hỗ trợ thông qua việc sử dụng cấu hình Máy chủ ảo. Bạn có thể định cấu hình máy chủ ảo cho TLS một chiều hoặc hai chiều.

TLS hướng Nam (apigee dưới dạng ứng dụng kết nối với dịch vụ phụ trợ) được hỗ trợ thông qua việc sử dụng cấu hình Máy chủ mục tiêu. Bạn có thể định cấu hình Máy chủ mục tiêu cho TLS một chiều hoặc hai chiều.

Apigee hỗ trợ nhiều tuỳ chọn cấu hình TLS.

Việc thực thi TLS 2 chiều đảm bảo rằng ứng dụng đang dùng một chứng chỉ đã được đưa vào Apigee. OWASP cũng cung cấp các phương pháp hay nhất về TLS.

Trong quá trình kết hợp Apigee, TLS được cung cấp ở đường truyền vào thông qua bí danh máy chủ lưu trữ, một khái niệm tương tự như máy chủ ảo.

Sau đây là các nguyên tắc bảo mật dữ liệu nhạy cảm:

  • Hãy sử dụng một nền tảng hỗ trợ TLS một chiều và hai chiều, vì vậy, hãy bảo vệ ở cấp giao thức.
  • Hãy sử dụng các chính sách như chính sáchSpecifyMessage và chính sách JavaScript để xoá dữ liệu nhạy cảm trước khi dữ liệu đó được trả về ứng dụng.
  • Sử dụng các kỹ thuật OAuth tiêu chuẩn và cân nhắc việc thêm HMAC, hàm băm, trạng thái, số chỉ dùng một lần, PKCE hoặc các kỹ thuật khác để cải thiện mức độ xác thực cho từng yêu cầu.
  • Sử dụng chế độ cài đặt che giấu dữ liệu để che giấu dữ liệu nhạy cảm trong công cụ Edge Trace.
  • Hãy cẩn thận khi lưu trữ mọi dữ liệu nhạy cảm trong bộ nhớ đệm (hoặc mã hoá dữ liệu nhạy cảm được lưu trữ trong bộ nhớ đệm). Trong Edge, bạn có thể mã hoá dữ liệu nhạy cảm khi lưu trữ trong bản đồ giá trị khoá.

A4:2017 – Các thực thể bên ngoài XML

Các hệ thống hoặc ứng dụng xử lý XML cần phải xử lý "tham chiếu thực thể bên ngoài" trong XML – tham chiếu đến các tệp hoặc dữ liệu được thay thế bằng dữ liệu thực tế trong quá trình xử lý XML. Nếu các ứng dụng hoặc trình xử lý XML đã cũ hoặc được triển khai không tốt, thì kẻ tấn công có thể tấn công và sử dụng dữ liệu đó để lấy cắp thông tin hoặc triển khai nhiều loại tấn công trên hệ thống, chẳng hạn như từ chối dịch vụ.

Chính sách ExtractVariables của Apigee cho phép bạn trích xuất nội dung từ một yêu cầu hoặc phản hồi và chỉ định nội dung đó cho một biến. Bạn có thể trích xuất bất kỳ phần nào của thông báo, bao gồm cả tiêu đề, đường dẫn URI, tải trọng JSON/XML, tham số biểu mẫu và tham số truy vấn. Chính sách này hoạt động bằng cách áp dụng một mẫu văn bản cho nội dung thông báo và sau khi tìm thấy kết quả trùng khớp, hãy đặt một biến có nội dung thông báo được chỉ định.

Apigee tích hợp sẵn một trình phân tích cú pháp XML trong nền tảng này sử dụng XPath để trích xuất dữ liệu. Mô-đun này cũng có chính sách XML BiddingProtection để bảo vệ chống lại các phần tải trọng XML độc hại.

A5:2017 – Điều khiển truy cập bị hỏng

Sau khi người dùng đăng nhập và có quyền truy cập vào hệ thống, bạn cần thiết lập các biện pháp kiểm soát uỷ quyền thích hợp để người dùng có thể xem và chỉ làm những việc họ được phép. Nếu không có các biện pháp kiểm soát quyền truy cập mạnh mẽ, kẻ tấn công có thể xem những dữ liệu trái phép và thường nhạy cảm hoặc thao túng dữ liệu và hành vi của hệ thống một cách ác ý.

Apigee hỗ trợ phương pháp phân lớp để triển khai các biện pháp kiểm soát quyền truy cập nhằm ngăn chặn đối tượng xấu thực hiện các thay đổi trái phép hoặc truy cập vào hệ thống.

Các chế độ kiểm soát quyền truy cập cho giao diện người dùng Edge

Các biện pháp kiểm soát quyền truy cập vào Cổng thông tin dành cho nhà phát triển Apigee

Kiểm soát quyền truy cập vào API thời gian chạy Apigee

  • Quyền truy cập vào API có thể được thực thi thông qua khoá API, mã thông báo OAuth, phạm vi OAuth, chứng chỉ và các kỹ thuật khác.
  • Nhà cung cấp API sẽ định cấu hình những tài nguyên hiện có bằng cách xác định một sản phẩm API. Bạn có thể cấp quyền truy cập theo cách thủ công trong giao diện người dùng, thông qua API quản lý hoặc thông qua cổng thông tin dành cho nhà phát triển. Khi ứng dụng của nhà phát triển được cấp quyền truy cập vào một sản phẩm API, họ sẽ nhận được một mã ứng dụng khách và mã bí mật dùng trong quá trình xác thực.
  • Apigee có thể tích hợp với bất kỳ nhà cung cấp danh tính nào để thực hiện OAuth.
  • Apigee có thể tạo mã thông báo JWT hoặc các kỹ thuật khác để gửi danh tính người dùng đến các dịch vụ mục tiêu. Các dịch vụ mục tiêu có thể sử dụng danh tính đó để hạn chế quyền truy cập vào các dịch vụ và dữ liệu khi cần.

A6:2017-Cấu hình sai bảo mật

Các cấu hình sai về bảo mật rất dễ bị bỏ qua vì quản trị viên và nhà phát triển nhầm lẫn rằng các hệ thống họ sử dụng vốn an toàn. Cấu hình sai bảo mật có thể xảy ra theo nhiều cách khác nhau, chẳng hạn như tin tưởng cấu hình mặc định hoặc tạo một phần cấu hình có thể không an toàn, để thông báo lỗi chứa thông tin nhạy cảm, lưu trữ dữ liệu trên đám mây mà không có các chế độ kiểm soát bảo mật phù hợp, định cấu hình sai tiêu đề HTTP, v.v. Nền tảng Apigee cung cấp một số cơ chế giúp bạn kiểm soát, quản lý và giám sát các cấu hình bảo mật, trong đó có các luồng dùng chung có thể sử dụng lại.

Luồng dùng chung cho phép nhà phát triển API kết hợp các chính sách và tài nguyên thành một nhóm có thể sử dụng lại. Bằng cách ghi lại chức năng có thể sử dụng lại ở một nơi, quy trình dùng chung giúp bạn đảm bảo tính nhất quán, rút ngắn thời gian phát triển và quản lý mã dễ dàng hơn. Bạn có thể đưa một luồng dùng chung vào bên trong từng proxy API hoặc tiến thêm một bước nữa bằng cách đặt các luồng dùng chung trong flow hook để tự động thực thi logic luồng dùng chung cho mọi proxy API được triển khai trong cùng một môi trường với luồng dùng chung.

Các bản phát hành sản phẩm Apigee giúp đảm bảo khả năng bảo vệ khỏi các thư viện có lỗ hổng bảo mật. Apigee có thể phát hành bản vá hoặc bản cập nhật bổ sung nếu phát hiện thấy các lỗ hổng mới. Đám mây công khai ở Edge được vá tự động. Khách hàng dùng Edge dành cho đám mây riêng tư (tại cơ sở hạ tầng riêng) phải tự áp dụng bản vá sản phẩm.

A7:2017 Viết tập lệnh trên nhiều trang web (XSS)

Tập lệnh trên nhiều trang web (XSS) cho phép kẻ tấn công thực thi các tập lệnh trong trình duyệt web của người dùng để kiểm soát phiên hoạt động của người dùng, thao túng trang web hoặc tác động ác ý đến người dùng theo những cách khác. Các vấn đề về XSS không nhất thiết liên quan đến API, nhưng Apigee cung cấp các chính sách bảo vệ khỏi các mối đe doạ có thể được tận dụng để bảo vệ chống lại XSS trong API. Bằng cách sử dụng các biểu thức chính quy, dù là bằng chính sách chính sách Thông thường ExpressionProtection hoặc chính sách JavaScript, hãy kiểm tra tải trọng và giá trị thông số cho JavaScript cũng như các cuộc tấn công loại chèn khác.

CORS là một trong những giải pháp được triển khai phổ biến cho chính sách cùng nguồn gốc (được thực thi trên tất cả trình duyệt) có thể được triển khai bằng cách sử dụng chính sách AssignmentsMessage.

A8:2017 – Huỷ chuyển đổi tuần tự không an toàn

Kẻ tấn công có thể sử dụng lỗ hổng trong quá trình huỷ chuyển đổi tuần tự cho nhiều loại tấn công, chẳng hạn như phát lại, chuyển đặc quyền lên cấp trên và chèn. Việc huỷ chuyển đổi tuần tự không an toàn cũng có thể cho phép thực thi mã từ xa.

Bạn không nên huỷ chuyển đổi tuần tự. Tuy nhiên, chính sách về JSONBảo vệ dữ liệu và chính sách Thông thườngExpressionProtection có thể giúp bảo vệ chống lại các tải trọng JSON độc hại. Bạn cũng có thể sử dụng chính sách JavaScript để quét nội dung độc hại trong các phần tải dữ liệu. Bộ nhớ đệm và các chính sách khác có thể được dùng để ngăn chặn các cuộc tấn công phát lại. Ở cấp độ cơ sở hạ tầng, nền tảng Apigee cũng tích hợp các biện pháp bảo vệ để bảo vệ các quy trình đang chạy.

A9:2017 – Sử dụng các thành phần có lỗ hổng bảo mật đã biết

Vì các khung, thư viện và mô-đun chạy với quyền truy cập CRUD và thực thi đầy đủ, nên những kẻ tấn công có thể tận dụng các lỗ hổng thành phần để tấn công các hệ thống.

Các bản phát hành sản phẩm định kỳ của Apigee giúp đảm bảo khả năng bảo vệ khỏi các lỗ hổng thành phần, đặc biệt là khi phát hiện các lỗ hổng cụ thể. Đám mây công khai của Apigee được vá tự động và Apigee sẽ thông báo cho khách hàng sử dụng dịch vụ Đám mây riêng tư Edge khi có thể cài đặt các bản vá tại cơ sở.

A10:2017 – Ghi nhật ký và giám sát không đầy đủ

Nếu bạn không thực hiện đầy đủ việc ghi nhật ký, giám sát và quản lý sự cố trong hệ thống của mình, những kẻ tấn công có thể thực hiện các cuộc tấn công sâu hơn và kéo dài hơn vào dữ liệu và phần mềm.

Apigee có một số cách để ghi nhật ký, giám sát, xử lý lỗi và ghi nhật ký kiểm tra.

Ghi nhật ký

  • Bạn có thể gửi thông điệp nhật ký đến Splunk hoặc điểm cuối nhật ký hệ thống khác bằng chính sách MessageLogging.
  • Dữ liệu phân tích API có thể được lấy thông qua API Analytics và được nhập hoặc xuất sang các hệ thống khác.
  • Trong Edge dành cho Đám mây riêng tư, bạn có thể dùng chính sách MessageLogging để ghi vào tệp nhật ký cục bộ. Các tệp nhật ký từ mỗi thành phần đang chạy cũng có sẵn.
  • Bạn có thể sử dụng chính sách JavaScript để gửi thông điệp nhật ký tới điểm cuối ghi nhật ký REST một cách đồng bộ hoặc không đồng bộ.

Giám sát

  • Sử dụng giao diện người dùng hoặc API Giám sát API để thường xuyên theo dõi các API và phần phụ trợ cũng như các cửa hàng cho phép kích hoạt.
  • Sử dụng tính năng theo dõi tình trạng để thường xuyên giám sát các phần phụ trợ của máy chủ mục tiêu.
  • Apigee đưa ra đề xuất về việc giám sát Edge dành cho đám mây riêng tư.
  • Apigee cũng cung cấp các phương pháp hay nhất mà nhóm của bạn có thể tận dụng để theo dõi chương trình API của mình.

Xử lý lỗi

Apigee cung cấp cơ chế xử lý lỗi mạnh mẽ, linh hoạt cho các proxy API. Tương tự như cách một chương trình Java sẽ phát hiện các trường hợp ngoại lệ, proxy API có thể phát hiện lỗi và xác định cách trả về phản hồi thích hợp cho ứng dụng. Khả năng xử lý lỗi tuỳ chỉnh của Apigee cho phép bạn thêm các chức năng như ghi nhật ký thông báo bất cứ khi nào xảy ra lỗi.

Nhật ký kiểm tra

Nền tảng Apigee lưu giữ một nhật ký kiểm tra để theo dõi các thay đổi về proxy API, sản phẩm và nhật ký của tổ chức. Nhật ký này được cung cấp thông qua giao diện người dùng hoặc API Kiểm tra.

Giải pháp Apigee dành cho các lỗ hổng bảo mật OWASP năm 2013

Khi OWASP cập nhật danh sách cho năm 2017, một số lỗ hổng bảo mật trong danh sách của năm 2013 đã bị loại bỏ. Chúng vẫn là những mối đe doạ vẫn còn hiệu lực. Các phần sau đây mô tả cách xử lý các mối đe doạ này bằng Apigee.

A8:2013 – Giả mạo yêu cầu trên nhiều trang web (CSRF)

Yêu cầu giả mạo trên nhiều trang web cho phép kẻ tấn công chuyển tiếp thông tin xác thực, cookie phiên và các dữ liệu khác của người dùng tới một ứng dụng web dễ bị tấn công qua HTTP, lừa ứng dụng web tin rằng các yêu cầu đó là các yêu cầu hợp lệ của người dùng.

Nguyên tắc:

  • Đây không phải là vấn đề về trình duyệt, chứ không phải vấn đề về sản phẩm API. Bạn có thể xử lý lỗ hổng bảo mật này bằng OpenSL Connect, OAuth và các kỹ thuật khác.
  • Hãy cân nhắc sử dụng các kỹ thuật HMAC, trạng thái, hàm băm, số chỉ dùng một lần hoặc PKCE để ngăn chặn hành vi giả mạo và các cuộc tấn công phát lại.

A10:2013 - Chuyển hướng và chuyển tiếp chưa được xác thực

Nếu một ứng dụng web thực hiện lệnh chuyển hướng, nhưng không xác thực rằng lệnh chuyển hướng đang đưa người dùng đến các trang web đáng tin cậy, có mục đích rõ ràng, thì kẻ tấn công có thể đưa người dùng đến các đích đến độc hại để thực hiện hành vi lừa đảo, thực thi phần mềm độc hại và các cuộc tấn công khác.

Nguyên tắc:

  • Sử dụng OAuth và thực thi xác thực ở mỗi yêu cầu.
  • Ngăn chặn lệnh chuyển hướng 302 không mong muốn bằng cách kiểm tra mã phản hồi trong logic proxy API và xử lý lệnh chuyển hướng một cách thích hợp.