AIDiveMở đầu: chạy nó lên chính mình trước
Hãy chĩa REA vào app của chính bạn trước khi có người khác mổ xẻ nó. Tụi mình đã chĩa nó vào site đang chạy thật của mình từ một sandbox đám mây dùng một lần, sửa những gì nó tìm ra, rồi gửi pull request.
REA là skill reverse engineering mà cả một làn sóng video đã chĩa vào phần mềm của người khác. Trên site của tụi mình, nó cần chưa tới mười ba phút và không một write request nào để chứng minh rằng website nào cũng có thể làm đầy danh sách email của tụi mình. Nó cũng tìm thấy giới hạn hằng ngày của bot trả lời bình luận nằm ngay trong JavaScript mà site tải xuống cho người truy cập. Sau bản sửa, request từng lọt qua giờ bị từ chối.
Kết quả là sáu quy tắc để chạy cùng kiểu audit này trên app của bạn: sandbox dùng một lần, URL chính xác, phân loại finding, config nằm trong bundle, phanh cho endpoint, và chứng minh bản sửa.
REA là gì, và cài đặt thế nào
REA là viết tắt của Reverse Engineer Anything: một bộ công cụ cho phép Claude Code mổ xẻ chính app bạn phát hành. Reverse engineering nghĩa là suy ra cách một thứ được tạo ra từ thành phẩm, giống như thợ máy đọc một chiếc xe khi không có bản vẽ của nhà máy.
Thay vì đọc source code của bạn, REA đọc bundle, tức là phần JavaScript mà site của bạn thực sự gửi tới mọi người truy cập. Từ bundle đó, nó liệt kê các route, các endpoint mà trang của bạn gọi, và mọi thứ bạn lỡ để lại trong đó. Nó không thể trả source về cho bạn, vì bạn chỉ nhận được bằng chứng, và tài liệu của chính nó cũng nói nó không phải là sandbox.
Để cài đặt:
- Cài REA từ package chính thức và ghim phiên bản, vì nó đã ra sáu bản phát hành trong một tuần.
- Chạy phần setup của nó cho Claude Code.
- Bật profile compact, vì nó nạp tới hơn một trăm tool vào session của bạn.
- Chỉ cài từ repo chính thức, vì các bản sao giả chứa malware đã bị lan truyền.
Khi chạy cài đặt trong sandbox, agent đầu tiên kiểm tra package có trỏ về repo chính thức không rồi mới đụng vào bất cứ thứ gì. Phần setup sau đó cài skill nhưng không cài tool server, nên Claude Code chỉ việc dùng các phiên bản dòng lệnh của cùng những tool đó. Nếu tool không hiện ra sau khi setup, bạn không cần khởi động lại gì cả: hãy gọi các bước tương tự từ terminal.
Quy tắc 1: chạy ở nơi nó không gây hại được
Quy tắc đầu tiên nói về nơi bạn chạy nó. Bạn sắp để một agent điều khiển trình duyệt và chạy các tool tải về nhắm vào app production của mình. Trên laptop của bạn, agent đó nằm cạnh các khóa, các dự án khác và mọi tài khoản bạn đang đăng nhập. Ghi chú bảo mật của chính REA nói thẳng: đây không phải sandbox.
Sandbox là một cỗ máy dùng một lần, nên bất cứ điều gì hỏng đều nằm gọn trong đó và bạn xóa nó đi. Hãy mở một sandbox dùng một lần trên repo của bạn và chạy toàn bộ audit ở đó, đừng bao giờ chạy trên máy của bạn.
Tụi mình dùng Kosuke, chạy Claude Code trên gói đăng ký của chính bạn bên trong một máy đám mây dùng một lần. Bạn chọn repo, nói cho deploy agent biết app khởi động thế nào, và nó cho bạn một preview, tức là một đường link nơi app đang chạy của bạn hiện ra. Mỗi cuộc chat cũng có branch riêng, nghĩa là bản sao code riêng, và kết thúc bằng một pull request. Khi tụi mình import site, agent tự cài trình quản lý package và một trình duyệt headless, đo bộ nhớ, và tự chọn cỡ máy. Vài phút sau, site thật của tụi mình đang chạy bên cạnh cuộc chat, trên một branch không ai khác đụng tới.
Một cái bẫy từ lần thử trước: một app Next.js mới tạo hiện ra trong preview, nhưng không có gì trên trang phản hồi. Cách sửa là một dòng trong config Next cho phép địa chỉ của preview, và trang sống lại.
Giới hạn là đây vẫn là Claude Code đó, chỉ được bọc trong một cái hộp, nên một máy ảo cục bộ hoặc một container làm việc y hệt. Điều quan trọng là cái hộp, không phải thương hiệu.
Công khai: Kosuke cho tụi mình dùng miễn phí gói cao nhất của họ. Nhập mã AIDIVE2026 vào ô "Promo code" ngay sau khi đăng ký để nhận 30 đô la credit thay vì 10 đô la như thường lệ.
Quy tắc 2: một URL chính xác, chặn mọi write
Quy tắc thứ hai là điều bạn thực sự nói với REA. Nếu bạn chỉ nói "audit app của tôi", skill của REA sẽ dừng lại và hỏi app nào.
REA cũng không bao giờ tự mở trình duyệt, nên bạn tự khởi động một cái với debug port, một cánh cửa cho phép tool theo dõi mọi việc trang làm. Hãy thiết lập theo thứ tự này:
- Giữ debug port trên loopback, địa chỉ chỉ máy của bạn mới truy cập được, và cho trình duyệt một profile mới tinh.
- Chặn mọi write request trước khi bất kỳ trang nào tải, để audit có thể đọc site của bạn nhưng không thể gửi form hay thay đổi gì.
- Chỉ sau đó mới đưa cho REA đúng những trang bạn muốn nó đọc.
Trong prompt của tụi mình, tụi mình nêu tên hai trang của câu lạc bộ miễn phí và viết một quy tắc bằng lời thường: không bao giờ gửi write tới site thật. Điều đó quan trọng, vì form trên các trang đó đổ vào một danh sách email thật với những con người thật. Agent nghiêm túc với quy tắc này và tự viết một guard nhỏ cho đọc đi qua và chặn mọi thứ còn lại. Trong lúc audit, guard đó đã chặn sáu lần thử từ script analytics, và không một request nào từng chạm tới form đăng ký của tụi mình.
REA sau đó làm phần việc của nó: kiểm tra từng trang, đọc từng bundle, chụp ảnh màn hình và xuất các script ra ngoài repo.
Giới hạn là REA chỉ quan sát những gì tải trong lúc nó được gắn vào, nên mọi thứ xảy ra trước đó vẫn là unknown trong báo cáo. Dù vậy, giờ bạn đã có một báo cáo về app đang chạy thật của mình, được viết mà không chạm vào một mẩu dữ liệu nào của nó.
Quy tắc 3: phân loại mọi finding trước khi sửa
Quy tắc thứ ba là phân loại trước khi sửa. Một báo cáo như thế này đầy những dòng đáng báo động và bạn sẽ muốn sửa hết cùng lúc.
Skill của chính REA muốn mọi kết luận được đánh dấu là quan sát, suy luận hoặc unknown, kèm một evidence ID. Đó là điều nó đã thấy, điều nó đoán, và điều nó không thể thấy, còn evidence ID là một biên nhận bạn có thể kiểm tra. Hãy phân loại mọi finding theo cách đó trước, chỉ dùng góc nhìn của người ngoài, và commit bản đó trước khi mở bất kỳ file source nào. Sau đó đọc source của bạn và đánh dấu từng dòng là rò rỉ thật, là chủ đích thiết kế, hay là false positive.
Báo cáo của tụi mình có mười lăm finding:
| Finding | REA thấy gì | Kết luận của tụi mình |
|---|---|---|
| Endpoint đăng ký | Không có giới hạn và không kiểm tra site nào đang gọi, nên website nào cũng có thể khiến trình duyệt của người truy cập đăng ký một địa chỉ bất kỳ vào danh sách của tụi mình | Rò rỉ thật, tệ nhất |
| Cổng email trên các gói miễn phí | Cả gói đã nằm sẵn trong trang bạn tải; một dòng trong console của trình duyệt là gỡ được cổng, hoặc chế độ đọc hiện ra văn bản | Chủ đích thiết kế |
| Source map, key, cookie | Không có trong bundle, không có cookie nào cả | Tin tốt |
Cổng này là chủ đích thiết kế vì các gói miễn phí là có chủ ý, và code của chính tụi mình ghi rằng một form hỏng không bao giờ được che một trang miễn phí.
Giới hạn là cột unknown. REA không thể thấy server của bạn làm gì, nên bạn giải quyết những dòng đó bằng cách đọc code server của mình.
Quy tắc 4: bundle của bạn phát hành cả config
Quy tắc thứ tư nói về những gì bundle của bạn mang theo, vì một file cài đặt dùng chung có thể đi tới mọi người truy cập mà bạn không hay biết.
Chuyện xảy ra thế này. Bạn import config trong một helper, và hai component tương tác nhỏ dùng helper đó. Bundler, công cụ đóng gói code của bạn thành các file mà trình duyệt tải về, không biết chúng cần những key nào, nên nó phát hành tất cả.
Đó chính xác là điều REA tìm thấy trong JavaScript của tụi mình. Toàn bộ config của site nằm trong một file, với ID danh sách email, các thư mục build, và những giới hạn của bot trả lời bình luận trên video của tụi mình. Nó còn cho biết bot đó gửi bao nhiêu câu trả lời mỗi ngày, một trăm, và bao nhiêu lỗi thì công tắc an toàn ngắt. Hai component kéo nó vào chỉ đọc tên site và danh sách ngôn ngữ.
Quy tắc: tìm các config key của chính bạn trong JavaScript đã phát hành, và chỉ đưa cho client component những trường nó đọc. Trong sandbox của tụi mình, agent đã tách config thành một bản nhỏ cho trình duyệt chỉ có những trường đó, phần còn lại ở trên server. Nó cũng thêm một bước build sẽ thất bại nếu một server key lại xuất hiện trong file đã phát hành, nên bạn không thể quay lại lỗi cũ.
Không có gì ở đây là mật khẩu, nhưng mọi thứ trong file đó đều công khai, vì vậy bí mật của bạn chỉ nên nằm trong biến của server.
Quy tắc 5: endpoint mở nào cũng cần một cái phanh
Quy tắc thứ năm sửa lỗ rò rỉ thật của tụi mình, và nó áp dụng bất cứ khi nào bạn có một form công khai gọi một dịch vụ trả phí: danh sách email, mô hình AI, hoặc cổng nhắn tin SMS của bạn. Bạn gọi nó qua một hàm server nhỏ viết trong một buổi chiều. Hàm của tụi mình nhận một email và chuyền thẳng cho danh sách email, và bất kỳ website nào khác cũng có thể khiến trình duyệt của người truy cập gửi nó.
Danh mục kiểm tra của giới bảo mật nói thẳng: kiểm soát truy cập chỉ hiệu quả trong code mà kẻ tấn công không thể thay đổi, tức là server của bạn. Vì vậy hãy đặt phanh cho mọi endpoint như vậy:
- Kiểm tra Origin. Header Origin là con dấu trình duyệt đóng lên một request để cho biết site nào đã gửi, nên form trên website khác sẽ bị từ chối.
- Rate limit. Một mức trần về số request một người truy cập có thể gửi trong một khoảng thời gian ngắn.
- Consent được kiểm tra trên server. Ô bạn tick thực sự đi cùng request.
Trong sandbox của tụi mình, agent đã viết tất cả vào Worker của tụi mình, hàm nhỏ chạy phía trước các trang khi bạn truy cập. Sau đó nó thử với một dịch vụ email giả, không bao giờ là dịch vụ thật, và mọi request đều bị từ chối đúng chỗ cần từ chối. Gửi từ sai site thì bị từ chối. Request thứ sáu trong một phút cũng bị từ chối, và không có consent thì bị loại.
Giới hạn là một script có thể giả con dấu Origin, và rate limit đếm theo vị trí, nên cách sửa thật cho điều đó là xác nhận kép qua email.
Quy tắc 6: chạy lại, tự kiểm tra, gửi PR
Quy tắc thứ sáu và cuối cùng là chứng minh bản sửa, vì một bức tường dấu tick xanh chính là lúc bạn ngừng nhìn kỹ. Một lập trình viên từng thử REA trên một app desktop đã viết trên HackerNoon rằng nó bỏ sót các entry point mà app thực sự có.
Vì vậy hãy chạy lại đúng các bước REA đó trên bản build đã sửa, tự kiểm tra từng bản sửa từ terminal, và chỉ sau đó mới mở pull request.
Trên bản build đã sửa, request từng lọt qua form đăng ký của tụi mình giờ bị từ chối. Các server key đã biến mất khỏi mọi file đã phát hành, các security header đã có đủ, và các test của Worker chuyển từ thất bại sang đạt. Cổng trên các gói miễn phí của tụi mình vẫn mở, đó là điều tụi mình quyết định, và báo cáo ghi rõ điều đó bên cạnh từng dòng.
Sau đó agent mở pull request. Các báo cáo nằm trong đó chỉ vì tụi mình yêu cầu trong prompt. Checklist kiểm thử mà Kosuke tạo ra vẫn nằm trong session, không có gì được đăng lên chính pull request. Nếu người review của bạn chỉ đọc GitHub, hãy tự đặt báo cáo trước và sau vào pull request.
Rồi tụi mình đưa cùng thay đổi đó vào code của chính mình, và nó sẽ chạy thật cùng lần deploy tiếp theo của site.
Kết luận: khi nào nên chạy REA lên chính mình
Toàn bộ lần chạy là REA chĩa vào site đang chạy thật của chính tụi mình từ một sandbox dùng một lần, mọi finding được phân loại, các rò rỉ thật được sửa, audit lại, và gửi đi dưới dạng pull request. Phát hiện biện minh cho tất cả là phát hiện đầu tiên: website nào cũng có thể làm đầy form đăng ký của tụi mình bằng địa chỉ của bất kỳ ai.
Hãy chạy audit này trước khi ra mắt bất cứ thứ gì có form công khai hoặc dịch vụ trả phí phía sau, và chạy lại mỗi khi bạn đổi những gì được phát hành. Đừng chạy nó trên phần mềm không phải của bạn, vì tuyên bố miễn trừ của chính REA giới hạn nó ở phần mềm bạn sở hữu hoặc được phép kiểm tra. Và nó không bao giờ thay thế việc đọc code server của bạn, vì đó chính xác là nơi các unknown nằm.
Nếu chỉ giữ một quy tắc, hãy giữ quy tắc này: chạy nó lên chính mình, trong một cái hộp, và chỉ sửa những gì bạn đã phân loại.
Prompt chính xác, bảng phân loại và bản sửa Worker mà tụi mình đã phát hành có trong bộ kit miễn phí của video này.
