Vào ngày 20 tháng 5 năm 2026, GitHub xác nhận rằng những kẻ tấn công đã đánh cắp dữ liệu từ khoảng 3.800 kho mã nội bộ của họ. Điểm xâm nhập không phải là một lỗ hổng zero-day trong các máy chủ của GitHub. Đó là một tiện ích mở rộng VS Code độc hại được cài đặt trên máy tính xách tay của một nhân viên. Khi tiện ích mở rộng đó chạy với các quyền hệ thống tệp tương tự như của nhà phát triển, nó có thể đọc mọi thứ trong tầm với: mã nguồn, tệp cấu hình và bất kỳ thông tin xác thực nào nằm trong không gian làm việc. Nếu bạn muốn bảo vệ khóa API khỏi cùng loại tấn công này, bài học đưa ra tuy khó chịu nhưng đơn giản. Mắt xích yếu nhất hiếm khi là đám mây. Đó chính là máy của nhà phát triển và các công cụ đang chạy trên đó.
TÓM TẮT
Để bảo vệ khóa API khỏi tiện ích mở rộng IDE bị xâm nhập hoặc kho lưu trữ bị rò rỉ, hãy ngừng lưu trữ thông tin xác thực trực tiếp ở nơi các công cụ phát triển có thể đọc được. Giữ bí mật ra khỏi mã nguồn và ra khỏi các tệp .env đã được commit. Hãy coi .gitignore là một tiện ích, không phải là một biện pháp kiểm soát bảo mật. Giới hạn mỗi khóa cho một môi trường duy nhất, sử dụng thông tin xác thực có thời gian sống ngắn và đặc quyền tối thiểu, đồng thời xoay vòng theo lịch trình. Các công cụ như Apidog giúp ích bằng cách giữ thông tin xác thực API trong các biến môi trường với các giá trị chỉ có trên cục bộ, thay vì các đoạn văn bản rõ ràng nằm rải rác trong kho lưu trữ và không gian làm việc của bạn.
Tại sao vụ vi phạm của GitHub là hồi chuông cảnh tỉnh cho mọi nhà phát triển
Vụ việc của GitHub giống như một cuộc tấn công chuỗi cung ứng điển hình. Nhóm mối đe dọa, được theo dõi với tên TeamPCP, có lịch sử cài mã độc Trojan vào các gói trong các hệ sinh thái npm, PyPI và PHP. Lần này, mã độc được đưa vào thông qua một tiện ích mở rộng VS Code. Theo báo cáo của TechCrunch, những kẻ tấn công đã đánh cắp dữ liệu từ khoảng 3.800 kho lưu trữ nội bộ và hiện đang bán bộ dữ liệu này với giá hơn 50.000 đô la trên các diễn đàn ngầm. GitHub cho biết họ không có bằng chứng nào cho thấy dữ liệu khách hàng được lưu trữ bên ngoài các kho lưu trữ nội bộ đó bị ảnh hưởng, và cuộc điều tra đang diễn ra.
Đây là phần nên khiến bạn suy nghĩ. Một tiện ích mở rộng VS Code chỉ là mã. Khi bạn cài đặt một tiện ích, nó chạy bên trong tiến trình của trình soạn thảo với quyền người dùng của bạn. Nó có thể liệt kê các tệp, mở và đọc nội dung của chúng. Nó có thể theo dõi các thay đổi của tệp. Nó có thể thực hiện các yêu cầu mạng ra bên ngoài. Không có điều nào trong số đó là một lỗ hổng; đó là mô hình tiện ích mở rộng hoạt động như thiết kế. Hầu hết các tiện ích mở rộng cần quyền truy cập tệp để thực hiện công việc của chúng. Vấn đề là một tiện ích mở rộng độc hại hoặc bị xâm nhập sử dụng cùng quyền truy cập đó để thu thập bất cứ thứ gì nó tìm thấy.
Nó tìm thấy gì? Trong một dự án thông thường, nó tìm thấy rất nhiều. Một tệp .env ở thư mục gốc của kho lưu trữ. Một tệp config/secrets.yml. Một token được mã hóa cứng trong một tập lệnh thử nghiệm nhanh mà bạn định xóa. Thông tin xác thực AWS trong ~/.aws/credentials. Một tệp .npmrc với token xác thực. Khóa SSH. Nhóm TeamPCP là tác nhân tương tự đứng sau chiến dịch sâu npm “Mini Shai-Hulud”, đã thu thập thông tin xác thực của nhà phát triển, CI/CD, đám mây và công cụ AI từ các máy bị nhiễm. Kiểu tấn công nhất quán: đưa mã chạy trên máy của nhà phát triển, sau đó quét tìm bất cứ thứ gì trông giống thông tin xác thực.
Điều này không mới về bản chất, chỉ mới về hình thức. Chúng tôi đã viết về một kiểu lộ thông tin tương tự trong phân tích của mình về các bài học bảo mật API từ vụ vi phạm của Vercel, và cơ chế chuỗi cung ứng phù hợp chặt chẽ với những gì chúng tôi đã đề cập trong hướng dẫn bảo mật chuỗi cung ứng npm. Sự cố GitHub là cùng một câu chuyện nhưng với một cái tên lớn hơn được gắn liền. Vì vậy, câu hỏi đáng hỏi hôm nay là trực tiếp: nếu một tiện ích mở rộng độc hại đang chạy trong trình soạn thảo của bạn ngay bây giờ, nó sẽ lấy đi những gì?
Khóa mã hóa cứng và tệp .env đã được commit là một lỗ hổng vĩnh viễn
Hầu hết các vụ rò rỉ thông tin xác thực đều không phức tạp. Chúng là do nhà phát triển dán một khóa vào mã “tạm thời” rồi quên đi, hoặc một tệp .env vô tình bị đưa vào một commit. Cả hai đều tạo ra một lỗ hổng tồn tại trong kho lưu trữ của bạn vô thời hạn.
Khóa mã hóa cứng là một lỗi rõ ràng. Bạn đã thấy mã như thế này:
import requests
# Quick test of the payments endpoint
STRIPE_KEY = "sk_live_51Qk2mNExampleKeyDoNotShipThis"
response = requests.post(
"https://api.stripe.com/v1/charges",
auth=(STRIPE_KEY, ""),
data={"amount": 2000, "currency": "usd", "source": "tok_visa"},
)
print(response.json())
Khóa sk_live_ đó giờ đã là một phần của tệp. Nó nằm trong thư mục làm việc của bạn, nơi bất kỳ tiện ích mở rộng nào cũng có thể đọc được. Nếu tệp được commit, khóa sẽ nằm trong lịch sử Git của bạn mãi mãi, ngay cả sau khi bạn xóa dòng đó trong một commit sau. Bất kỳ ai sao chép kho lưu trữ, hoặc bất kỳ công cụ nào quét nó, đều có được khóa đó.
Tệp .env được cho là giải pháp. Ý tưởng này hợp lý: giữ bí mật ra khỏi mã, tải chúng vào thời gian chạy. Một tệp .env thực tế trông như thế này:
# .env (loaded at runtime, never meant to ship)
DATABASE_URL=postgres://app_user:Zk7%2BqN9wLx@db.internal:5432/payments
STRIPE_SECRET_KEY=sk_live_51Qk2mNExampleKeyDoNotShipThis
OPENAI_API_KEY=sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890
AWS_ACCESS_KEY_ID=AKIA4EXAMPLE7QRSTUVW
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
JWT_SIGNING_SECRET=8f2a91c4e7b6d3508f2a91c4e7b6d350
Điều này tốt hơn việc mã hóa cứng. Nhưng hãy lưu ý điều nó không thay đổi. Tệp đó vẫn nằm trong không gian làm việc của bạn, ở dạng văn bản thuần túy, có thể đọc được bởi mọi tiến trình mà trình soạn thảo chạy. Một tiện ích mở rộng độc hại không quan tâm liệu bí mật của bạn nằm trong app.py hay trong .env. Cả hai đều là tệp. Cả hai đều chỉ cách một lệnh fs.readFileSync. Mẫu .env chỉ giải quyết vấn đề “bí mật trong lịch sử Git” nếu tệp đó không bao giờ được commit, và nó hoàn toàn không giúp gì cho vấn đề “công cụ cục bộ bị xâm nhập”.
Tệp .env đã được commit là kết quả tồi tệ nhất. Điều này phổ biến một cách đáng báo động. Một nhà phát triển thêm tệp .env vào dự án, ghi các khóa thực vào đó và quên không bỏ qua nó trước commit đầu tiên. Hoặc một đồng đội sao chép kho lưu trữ, thấy tệp .env.example, sao chép nó thành .env, điền khóa sản xuất vào, và một lệnh git add . sau đó sẽ đưa nó vào. Giờ đây, thông tin xác thực sản xuất nằm trong lịch sử chung của một kho lưu trữ có thể công khai, có thể được nhân bản, hoặc có thể kết thúc trong một vụ vi phạm như của GitHub. Chúng tôi đi sâu hơn về góc độ rò rỉ kho lưu trữ trong bài viết bổ trợ của mình về tài liệu API và bảo mật kho lưu trữ Git.
.gitignore không phải là một biện pháp kiểm soát bảo mật
Phần này xứng đáng có một mục riêng vì sự hiểu lầm rất phổ biến. Việc thêm .env vào .gitignore có cảm giác như khóa cửa. Nó không phải vậy. Đó là một ghi chú dán nói rằng “xin đừng nhặt cái này lên.”
Đây là những gì .gitignore thực sự làm. Nó yêu cầu Git bỏ qua các tệp chưa được theo dõi khớp với một mẫu khi bạn chạy git add. Đó là toàn bộ phạm vi. Nó có ba chế độ lỗi quan trọng đối với bảo mật:
- Nó không làm gì đối với các tệp đã được theo dõi. Nếu tệp
.envđã được commit một lần, trước khi bạn thêm quy tắc bỏ qua, Git vẫn tiếp tục theo dõi nó. Quy tắc bỏ qua bị ghi đè một cách thầm lặng. Bạn phải chạygit rm --cached .envvà commit việc xóa đó, và bí mật vẫn còn trong mọi commit lịch sử. - Nó không làm gì đối với tệp trên đĩa.
.gitignorelà một chỉ dẫn của Git. Tệp.envvẫn nằm trong thư mục làm việc của bạn ở dạng văn bản thuần túy. Một tiện ích mở rộng VS Code độc hại đọc hệ thống tệp, không phải chỉ mục Git. Quy tắc bỏ qua của bạn là vô hình đối với nó. Đây là chế độ lỗi quan trọng nhất đối với kiểu tấn công như của GitHub. - Chỉ cần một sai lầm là có thể bị bỏ qua. Lệnh
git add -f .envbỏ qua quy tắc bỏ qua. Việc thêm tệp thông qua giao diện điều khiển mã nguồn của trình soạn thảo cũng vậy. Hoặc một tệp.gitignorekhác trong thư mục con không lặp lại mẫu.
Bạn có thể tự xác nhận điểm đầu tiên. Nếu bạn nghi ngờ một bí mật đã từng được commit, lệnh này sẽ cho bạn thấy:
# Liệt kê mọi commit đã từng chạm vào tệp, ngay cả khi nó hiện bị "bỏ qua"
git log --all --full-history --oneline -- .env
# Xem các giá trị bí mật thực tế vẫn còn trong lịch sử
git log -p --all -- .env | grep -iE "key|secret|token|password"
Nếu lệnh đó trả về bất cứ điều gì, thông tin xác thực sẽ bị lộ ngay khi kho lưu trữ bị phơi bày. Cách khắc phục không phải là một quy tắc bỏ qua tốt hơn. Cách khắc phục là xoay vòng khóa và xóa tệp khỏi lịch sử bằng một công cụ như git filter-repo. Cách khắc phục sâu xa hơn là đảm bảo thông tin xác thực trực tiếp không bao giờ nằm trong một tệp ngay từ đầu.
.gitignore vẫn đáng để sử dụng. Nó giúp phát hiện những lỗi vô ý và giữ cho các bản khác biệt của bạn sạch sẽ. Đừng nhầm lẫn nó với một ranh giới mà kẻ tấn công tôn trọng. Đó là vệ sinh, không phải phòng thủ.
Phạm vi, tách biệt, rút ngắn, xoay vòng: bốn thói quen thu hẹp phạm vi ảnh hưởng
Bạn không thể đảm bảo một thông tin xác thực sẽ không bao giờ bị rò rỉ. Bạn có thể đảm bảo rằng thông tin xác thực bị rò rỉ gần như vô giá trị. Bốn thói quen sau đây sẽ làm hầu hết công việc đó.
Giới hạn bí mật theo môi trường
Một khóa bị rò rỉ chỉ nên mở khóa một thứ, chứ không phải toàn bộ hệ thống của bạn. Lỗi giới hạn phạm vi phổ biến nhất là sử dụng cùng một khóa API trong môi trường phát triển, thử nghiệm và sản xuất vì nó dễ dàng hơn. Khi khóa đó bị rò rỉ, mọi môi trường đều bị ảnh hưởng cùng lúc.
Cấp cho mỗi môi trường thông tin xác thực riêng. Máy cục bộ của bạn sử dụng khóa phát triển với quyền truy cập vào một dự án sandbox và dữ liệu thử nghiệm. Môi trường staging sử dụng khóa staging. Môi trường sản xuất sử dụng khóa sản xuất chỉ tồn tại ở một nơi duy nhất và không bao giờ được sao chép vào máy tính xách tay. Nếu khóa phát triển bị rò rỉ thông qua một tiện ích mở rộng bị xâm nhập, kẻ tấn công sẽ truy cập vào một sandbox với dữ liệu khách hàng giả. Đó là một sự phiền toái, không phải một sự cố nghiêm trọng.
Tách biệt các môi trường một cách hợp lý
Việc tách biệt môi trường không chỉ là ba giá trị khóa khác nhau. Nó có nghĩa là các môi trường không thể truy cập lẫn nhau. Cơ sở dữ liệu phát triển là một cơ sở dữ liệu khác, không phải là bản sao chỉ đọc của sản xuất. Nhà cung cấp thanh toán staging đang ở chế độ thử nghiệm của nhà cung cấp, do đó một khóa staging bị rò rỉ sẽ không thực hiện bất kỳ giao dịch thực nào. Các công cụ và con người không nên có khả năng trỏ một cấu hình “dev” tới dữ liệu sản xuất chỉ bằng cách thay đổi một biến.
Khi sự tách biệt là có thật, câu hỏi “khóa này đến từ môi trường nào?” sẽ có câu trả lời rõ ràng, và câu trả lời đó cho bạn biết chính xác mức độ nghiêm trọng của vụ rò rỉ.
Sử dụng khóa có đặc quyền tối thiểu, thời gian sống ngắn
Hai thuộc tính quyết định mức độ thiệt hại mà một khóa bị đánh cắp gây ra.
Đặc quyền. Một khóa nên mang tập hợp quyền hạn hẹp nhất mà công việc của nó yêu cầu. Một bản dựng frontend đọc danh mục sản phẩm công khai cần một khóa chỉ đọc được giới hạn cho tài nguyên đó. Nó không cần quyền ghi, không cần quyền truy cập thanh toán, và chắc chắn không cần quyền quản trị. Hầu hết các nhà cung cấp API đều hỗ trợ khóa giới hạn phạm vi hoặc token có quyền hạn chi tiết; token truy cập cá nhân chi tiết của GitHub là một mô hình tốt. Nếu bạn đang cân nhắc các kiểu token, bài so sánh của chúng tôi về khóa API so với OAuth sẽ giải thích khi nào token OAuth có thời gian sống ngắn vượt trội hơn hẳn các khóa tĩnh.
Thời gian sống. Một khóa hết hạn trong một giờ là một phần thưởng kém giá trị. Đến khi kẻ tấn công mua một bộ dữ liệu bị đánh cắp và tiếp cận được khóa của bạn, nó đã hết hạn. Các khóa tĩnh tồn tại mãi mãi thì ngược lại: chúng hoạt động cho đến khi ai đó phát hiện ra, thường là sau nhiều tháng. Ưu tiên các token có thời gian sống ngắn được cấp theo yêu cầu. Trường hợp khóa có thời gian sống dài là không thể tránh khỏi, hãy đặt thời gian hết hạn ngắn nhất mà quy trình làm việc cho phép.
Xoay vòng theo lịch trình, không phải trong hoảng loạn
Xoay vòng là thay đổi giá trị của thông tin xác thực để cái cũ không còn hoạt động. Hầu hết các nhóm chỉ xoay vòng sau một vụ vi phạm, trong vội vã, dưới áp lực. Đó là thời điểm tồi tệ nhất để biết rằng quy trình xoay vòng của bạn chưa được ghi lại.
Thay vào đó, hãy xoay vòng theo lịch. Chọn một khoảng thời gian cho mỗi loại thông tin xác thực; khóa sản xuất có đặc quyền cao hàng tháng, khóa rủi ro thấp hơn hàng quý. Việc xoay vòng thường xuyên làm hai việc. Nó giới hạn thời gian hữu ích của bất kỳ rò rỉ nào bạn chưa phát hiện, vì một khóa bị đánh cắp hôm nay sẽ ngừng hoạt động vào chu kỳ tiếp theo. Và nó duy trì cơ chế, cập nhật giá trị trong mọi môi trường tiêu thụ, được thực hiện một cách nhàm chán và thường xuyên. Khi một sự cố thực sự xảy ra, việc xoay vòng chỉ là một nút bạn đã nhấn năm mươi lần, chứ không phải là một buổi diễn tập khẩn cấp. Để hiểu rõ hơn, hãy xem tổng hợp của chúng tôi về các công cụ quản lý khóa API.
Giữ thông tin xác thực trong biến môi trường Apidog, không để lộ trong không gian làm việc của bạn
Đây là cách trình bày thẳng thắn. Apidog cung cấp một tiện ích mở rộng VS Code và một máy chủ MCP riêng. Luận điểm không phải là “công cụ của chúng tôi miễn nhiễm với loại tấn công đã xảy ra với GitHub.” Không có công cụ phía client nào miễn nhiễm. Luận điểm là về nơi bí mật của bạn được lưu trữ và mức độ phơi bày của chúng khi có điều gì đó trên máy của bạn hoạt động sai.
Hãy nghĩ về kịch bản thực tế. Bạn đang xây dựng và thử nghiệm API cả ngày. Bạn cần một bearer token, một khóa API, một chuỗi kết nối cơ sở dữ liệu. Cách thông thường là đưa chúng vào một tệp .env hoặc một tập lệnh để client của bạn có thể sử dụng. Điều đó đặt thông tin xác thực trực tiếp vào các tệp văn bản thuần túy trong không gian làm việc, chính là bề mặt mà một tiện ích mở rộng độc hại có thể quét. Hệ thống môi trường của Apidog thay đổi vị trí của các giá trị đó.
Biến môi trường thay vì tệp văn bản thuần túy
Trong Apidog, bạn lưu trữ thông tin xác thực dưới dạng biến môi trường thay vì văn bản rời rạc trong kho lưu trữ của bạn. Một yêu cầu tham chiếu biến theo tên, như {{access_token}} trong tiêu đề Authorization, và Apidog sẽ phân giải nó tại thời điểm gửi. Tiêu đề trong định nghĩa yêu cầu của bạn sẽ là Bearer {{access_token}}, chứ không phải Bearer sk-proj-aB3dEf.... Bí mật thực tế không nằm trong một tệp .env ở thư mục gốc của dự án chờ được đọc.
Điều này quan trọng vì cùng lý do mà .env tốt hơn mã hóa cứng, và còn tiến thêm một bước. Thông tin xác thực không còn là một dòng văn bản thuần túy trong một tệp nằm cạnh mã nguồn của bạn. Nó là một giá trị được quản lý bên trong client API, được tham chiếu gián tiếp.Giá trị cục bộ giữ bí mật trên máy của bạn
Apidog phân biệt rõ ràng giữa hai loại giá trị cho mỗi biến. Có một giá trị được chia sẻ, hoặc ban đầu, được đồng bộ hóa với máy chủ của Apidog và hiển thị cho nhóm của bạn. Và có một giá trị cục bộ, hoặc hiện tại, nằm trên máy của bạn và không bao giờ được tải lên. Hướng dẫn chính thức nêu rõ: đặt dữ liệu nhạy cảm như token và mật khẩu vào giá trị cục bộ để nó không bao giờ rời khỏi client của bạn.
Hiệu quả thực tế là một đồng đội sao chép cấu trúc dự án sẽ nhận được tên và định dạng biến, access_token, db_password, và các biến khác, nhưng không phải bí mật thực tế của bạn. Mỗi nhà phát triển điền giá trị cục bộ của riêng họ. Không có token sản xuất trực tiếp nào của ai được đưa vào dữ liệu dự án đã đồng bộ hóa, và không có tệp khóa thực tế nào được chia sẻ để bị rò rỉ.
Quản lý môi trường và cách ly môi trường
Quản lý môi trường của Apidog được xây dựng dựa trên thói quen giới hạn phạm vi từ phần trước. Bạn định nghĩa các môi trường riêng biệt, Phát triển (Development), Thử nghiệm (Staging), Sản xuất (Production), và mỗi môi trường mang URL cơ sở riêng cùng với bộ giá trị biến riêng của nó. Các biến được giới hạn theo môi trường: chỉ các giá trị của môi trường đang hoạt động có hiệu lực, và việc chuyển đổi môi trường sẽ chuyển đổi toàn bộ bộ thông tin xác thực cùng một lúc.
Điều này mang lại cho bạn sự cô lập môi trường theo cấu trúc. Biến payment_api_key của bạn chứa khóa sandbox trong môi trường Development và khóa sản xuất trong môi trường Production. Bạn không bao giờ chỉnh sửa một yêu cầu để chuyển đổi giữa chúng; bạn chuyển đổi môi trường. Bởi vì các giá trị được ràng buộc với môi trường, một thông tin xác thực phát triển không thể vô tình kết thúc trong một lệnh gọi sản xuất, và một bí mật sản xuất không bao giờ phải tồn tại trong môi trường phát triển cục bộ của bạn. Một môi trường phát triển bị rò rỉ sẽ phơi bày các giá trị phát triển. Môi trường sản xuất vẫn không bị ảnh hưởng.
Đối với các nhóm cần một ranh giới cứng: bí mật trong kho lưu trữ
Nếu nhóm của bạn cần các bí mật sản xuất không bao giờ chạm vào client API, gói Enterprise của Apidog bổ sung tính năng Vault Secret cho phép lấy bí mật trực tiếp từ HashiCorp Vault, Azure Key Vault hoặc AWS Secrets Manager. Apidog chỉ lưu trữ đường dẫn vault và siêu dữ liệu. Các giá trị bí mật thực tế được lấy theo yêu cầu, được mã hóa trong client cục bộ và không bao giờ được chia sẻ với đồng đội thông qua dự án. Nơi lưu trữ thông tin xác thực vẫn là trình quản lý bí mật chuyên dụng, đây chính xác là nơi mà một thông tin xác thực sản xuất nên tồn tại.
Để thử quy trình làm việc với biến môi trường, hãy Tải xuống Apidog, tạo một dự án, mở Quản lý Môi trường và thêm thông tin xác thực của bạn dưới dạng biến môi trường với các giá trị chỉ có trên cục bộ. Điều này chỉ mất vài phút và giúp đưa các bí mật trực tiếp ra khỏi các tệp văn bản thuần túy mà một tiện ích mở rộng có thể đọc.
Một lời cảnh báo chân thành. Việc chuyển bí mật vào Apidog giảm số lượng thông tin xác thực văn bản thuần túy nằm trong kho lưu trữ và không gian làm việc của bạn. Điều này không làm cho máy của bạn miễn nhiễm với một công cụ bị xâm nhập. Phòng thủ theo chiều sâu vẫn được áp dụng: kiểm tra các tiện ích mở rộng bạn cài đặt, giữ khóa sản xuất có đặc quyền tối thiểu và thời gian sống ngắn, và xoay vòng theo lịch trình. Apidog xử lý phần “thông tin xác thực nằm ở đâu”. Phần còn lại vẫn tùy thuộc vào bạn.
Kết luận
Vụ vi phạm của GitHub là một tín hiệu rõ ràng. Những kẻ tấn công đã nhận ra rằng máy của nhà phát triển, với các công cụ đáng tin cậy và các tệp cấu hình văn bản thuần túy của nó, là một mục tiêu dễ hơn bất kỳ máy chủ sản xuất nào. Bạn không thể làm cho máy đó hoàn toàn an toàn. Bạn có thể đảm bảo rằng một tiện ích mở rộng IDE bị xâm nhập hoặc một kho lưu trữ bị rò rỉ chỉ cung cấp rất ít thông tin cho kẻ tấn công.
Bắt đầu bằng một cuộc kiểm tra. Mở kho lưu trữ bạn làm việc nhiều nhất và tìm kiếm các từ khóa key, secret, token, và password. Kiểm tra xem tệp .env có trong lịch sử Git của bạn không. Bất cứ điều gì bạn tìm thấy, hãy coi nó là bị lộ: xoay vòng nó, sau đó di chuyển giá trị trực tiếp đến nơi mà một công cụ lạc không thể đọc được. Tải xuống Apidog và đặt bộ thông tin xác thực API tiếp theo của bạn vào các biến môi trường thay vì một tệp văn bản thuần túy. Để có bối cảnh rộng hơn, các bài viết bổ trợ của chúng tôi về các công cụ API tự lưu trữ sau vụ vi phạm của GitHub và các công cụ quản lý khóa API là những bài đọc hữu ích tiếp theo.
Câu hỏi thường gặp
Tiện ích mở rộng VS Code có thực sự có thể đọc tệp .env và khóa API của tôi không?
Có. Một tiện ích mở rộng VS Code chạy bên trong tiến trình của trình soạn thảo với quyền truy cập tệp của tài khoản người dùng của bạn. Nó có thể liệt kê các thư mục, mở tệp và đọc nội dung của chúng, bao gồm các tệp .env, tệp cấu hình và tệp thông tin xác thực như ~/.aws/credentials. Đây là hành vi bình thường của tiện ích mở rộng, vì nhiều tiện ích thực sự cần quyền truy cập tệp. Rủi ro là một tiện ích mở rộng độc hại hoặc bị xâm nhập sử dụng cùng quyền truy cập đó để thu thập bí mật. Đó là cơ chế đằng sau vụ vi phạm GitHub vào tháng 5 năm 2026.
Việc thêm .env vào .gitignore có đủ để bảo vệ khóa API không?
Không. .gitignore chỉ yêu cầu Git bỏ qua các tệp chưa được theo dõi trong quá trình git add. Nó không làm gì đối với các tệp đã được commit trước khi quy tắc tồn tại, và bí mật vẫn còn trong lịch sử Git bất kể điều đó. Nó cũng không làm gì đối với tệp trên đĩa: tệp .env vẫn nằm trong không gian làm việc của bạn ở dạng văn bản thuần túy, có thể đọc được hoàn toàn bởi bất kỳ công cụ hoặc tiện ích mở rộng cục bộ nào. Hãy coi .gitignore như một cách để ngăn chặn các lỗi vô ý, chứ không phải là một ranh giới bảo mật.
Tôi nên làm gì nếu tôi tìm thấy khóa API trong lịch sử Git của mình?
Coi nó là đã bị xâm phạm ngay lập tức, ngay cả khi kho lưu trữ là riêng tư. Đầu tiên hãy xoay vòng khóa để giá trị bị lộ ngừng hoạt động. Sau đó, xóa tệp khỏi lịch sử bằng một công cụ như git filter-repo, và force-push lịch sử đã được làm sạch sau khi phối hợp với nhóm của bạn. Cuối cùng, di chuyển thông tin xác thực trực tiếp ra khỏi bất kỳ tệp văn bản thuần túy nào để tránh sự rò rỉ tương tự xảy ra lần nữa. Xem hướng dẫn các công cụ quản lý khóa API của chúng tôi để biết các thực hành liên tục.
Việc lưu trữ khóa API trong Apidog giảm thiểu rủi ro bị lộ như thế nào?
Apidog cho phép bạn lưu trữ thông tin xác thực dưới dạng biến môi trường và tham chiếu chúng bằng tên trong các yêu cầu, do đó bí mật thực tế không nằm trong tệp .env văn bản thuần túy trong kho lưu trữ của bạn. Mỗi biến hỗ trợ một giá trị chỉ có trên cục bộ, nằm trên máy của bạn và không bao giờ đồng bộ hóa với máy chủ hoặc đồng đội, đây là nơi tài liệu khuyến nghị giữ token và mật khẩu. Các biến được giới hạn theo môi trường cũng giữ thông tin xác thực phát triển và sản xuất riêng biệt. Nó giảm số lượng bí mật trực tiếp nằm trong các tệp mà một công cụ có thể quét; nó không làm cho máy của bạn miễn nhiễm với một công cụ bị xâm nhập.
Apidog cũng có tiện ích mở rộng VS Code, vậy đó có phải là một rủi ro không?
Có, Apidog cung cấp một tiện ích mở rộng VS Code và một máy chủ MCP. Mục đích của bài viết này không phải là nói rằng bất kỳ công cụ nào cũng miễn nhiễm với các cuộc tấn công chuỗi cung ứng; không có công cụ phía client nào miễn nhiễm. Vấn đề là nơi bí mật của bạn được lưu trữ. Việc giữ thông tin xác thực trong các biến môi trường với các giá trị chỉ có trên cục bộ, hoặc trong tích hợp vault, có nghĩa là ít khóa văn bản thuần túy hơn sẽ bị lộ nếu bất kỳ công cụ nào trên máy của bạn, bao gồm cả tiện ích mở rộng của Apidog, bị xâm phạm. Phòng thủ theo chiều sâu, kiểm tra tiện ích mở rộng, đặc quyền tối thiểu và xoay vòng vẫn được áp dụng.
Sự khác biệt giữa việc giới hạn phạm vi và xoay vòng khóa API là gì?
Giới hạn phạm vi hạn chế những gì một khóa có thể làm và nơi nó áp dụng: khóa phát triển chỉ truy cập sandbox, và khóa chỉ đọc không thể ghi. Xoay vòng thay đổi giá trị của khóa theo lịch trình để giá trị cũ ngừng hoạt động. Giới hạn phạm vi thu hẹp thiệt hại mà một khóa bị rò rỉ có thể gây ra; xoay vòng thu hẹp khung thời gian mà khóa bị rò rỉ vẫn hữu ích. Bạn cần cả hai. Khi được sử dụng cùng nhau, một khóa bị đánh cắp sẽ mở khóa được rất ít và hết hạn sớm.
Tôi nên xoay vòng khóa API bao lâu một lần?
Xoay vòng theo lịch trình cố định thay vì chỉ sau một sự cố. Một tiêu chuẩn hợp lý là hàng tháng cho các thông tin xác thực sản xuất có đặc quyền cao và hàng quý cho các khóa có rủi ro thấp hơn, điều chỉnh theo mức độ chấp nhận rủi ro và bất kỳ quy tắc tuân thủ nào của bạn. Việc xoay vòng theo lịch trình giới hạn thời gian hữu ích của các vụ rò rỉ mà bạn chưa phát hiện và giữ cho quy trình xoay vòng được thực hành tốt, để một sự cố thực tế trở thành việc thường ngày chứ không phải là một sự vội vã.
Khóa API sản xuất có nên được lưu trên máy tính xách tay của nhà phát triển không?
Lý tưởng nhất là không. Thông tin xác thực sản xuất nên tồn tại ở càng ít nơi càng tốt, thông thường là một trình quản lý bí mật chuyên dụng và môi trường chạy sản xuất, không bao giờ được sao chép vào máy của nhà phát triển. Các nhà phát triển nên làm việc với thông tin xác thực phát triển hoặc thử nghiệm được giới hạn phạm vi cho dữ liệu không sản xuất. Nếu một máy tính xách tay bị xâm phạm, kẻ tấn công sẽ truy cập vào một sandbox, chứ không phải các hệ thống khách hàng thực tế. Việc cách ly môi trường và tích hợp vault của Apidog hỗ trợ điều này bằng cách giữ các giá trị sản xuất ra khỏi môi trường phát triển cục bộ.