10 giải pháp bảo mật cho website Vibe Coding trước Production
- Hung Pham
- 2 ngày trước
- 16 phút đọc
Website được tạo bằng AI đã chạy đúng chức năng chưa phải là điều kiện đủ để đưa lên production.
Trước khi cho người dùng thật đăng nhập, tải dữ liệu hoặc thực hiện giao dịch, doanh nghiệp cần kiểm tra cách ứng dụng bảo vệ secret, API, tài khoản, dữ liệu và hạ tầng.
Bài viết này tập trung vào 10 giải pháp bảo mật cho website vibe coding, kèm cách thực hiện, cách kiểm tra và tiêu chí hoàn thành.
Để tìm hiểu riêng về các nhóm rủi ro, xem bài Website Vibe Coding có an toàn không? 7 rủi ro cần kiểm tra hoặc bài phân tích về rủi ro vibe coding đối với doanh nghiệp.
Checklist bảo mật website Vibe Coding nhanh
Trước production, hãy bảo đảm:
Không có secret trong code và frontend.
Mọi API nhạy cảm đều xác thực tại backend.
Quyền được kiểm tra trên từng tài nguyên.
Dữ liệu đầu vào được validate tại server.
File upload được kiểm soát.
Dependency do AI đề xuất đã được xác minh.
Repository đã chạy SAST, SCA và secret scanning.
Ứng dụng staging đã được kiểm thử động.
API đã được thử với request sai quyền.
AI coding agent không có production credential.
CORS, cookie, HTTPS, database và storage đã được hardening.
Hệ thống có rủi ro cao đã được pentest.
Nếu một mục quan trọng chưa hoàn thành, website chưa nên được xem là sẵn sàng về bảo mật.
1. Xác định yêu cầu bảo mật trước khi yêu cầu AI viết code
Một lỗi phổ biến của vibe coding là prompt chỉ mô tả tính năng:
“Tạo trang quản lý hóa đơn cho khách hàng.”
Prompt không nói rõ:
ai được xem hóa đơn;
ai được chỉnh sửa;
tenant được tách biệt thế nào;
dữ liệu nào phải mã hóa;
thao tác nào cần audit log;
session tồn tại bao lâu;
API nào được public;
điều gì phải xảy ra khi request sai quyền.
Khi yêu cầu bảo mật không được viết rõ, AI có xu hướng ưu tiên hoàn thành chức năng nhìn thấy được.
NIST SSDF khuyến nghị đưa yêu cầu và hoạt động bảo mật vào toàn bộ vòng đời phát triển thay vì chỉ kiểm tra ở cuối.
Cách thực hiện
Trước mỗi tính năng, tạo một security specification ngắn.
Ví dụ:
Tính năng: Xem hóa đơn.
Quy tắc bảo mật:
Người dùng phải đăng nhập.
Chỉ được xem hóa đơn thuộc tenant của mình.
Nhân viên chỉ được xem hóa đơn được phân công.
Admin được xem toàn bộ trong tenant.
Mọi lần tải file phải được ghi log.
URL tải file có thời hạn.
API không trả trường dữ liệu nội bộ.
Không tin tenant_id do frontend gửi.
Prompt tốt hơn
Thay vì:
“Viết API lấy hóa đơn.”
Có thể dùng:
“Viết API lấy hóa đơn. Xác thực bằng session tại backend. Lấy user ID và tenant ID từ session đã xác minh, không lấy từ request body. Kiểm tra quyền trên từng hóa đơn. Trả 404 cho tài nguyên không thuộc quyền. Chỉ trả các trường nằm trong response schema. Thêm test cho trường hợp user A truy cập hóa đơn của user B.”
Prompt chi tiết không thay thế kiểm thử, nhưng giúp giảm khả năng AI bỏ qua yêu cầu quan trọng.
Điều kiện hoàn thành
Mỗi tính năng nhạy cảm có quy tắc xác thực và phân quyền.
Dữ liệu nhạy cảm đã được phân loại.
Trust boundary đã được xác định.
Có negative test case trước khi code được merge.
Không chỉ mô tả happy path.
2. Tách secret khỏi mã nguồn và frontend
Kiểm tra toàn bộ vị trí có thể chứa:
API key;
database password;
JWT secret;
OAuth client secret;
webhook secret;
private key;
cloud credential;
service account credential.
OWASP khuyến nghị quản lý tập trung quá trình lưu trữ, cấp phát, kiểm toán và xoay vòng secret.
Secret nên được lưu ở đâu?
Tùy hạ tầng, có thể dùng:
AWS Secrets Manager;
Google Cloud Secret Manager;
Azure Key Vault;
HashiCorp Vault;
secret store của nền tảng triển khai;
hệ thống quản lý secret nội bộ.
Không lưu giá trị thật trong:
source code;
frontend bundle;
tài liệu;
ticket;
prompt;
Dockerfile;
file cấu hình được commit;
log;
ảnh chụp màn hình.
Quét ở đâu?
Quét:
Code hiện tại.
Lịch sử Git.
Pull request cũ.
Build artifact.
Frontend bundle.
Container image.
Cấu hình CI/CD.
Log.
File backup.
Có thể sử dụng:
Gitleaks;
TruffleHog;
GitHub secret scanning;
GitLab secret detection;
công cụ tương đương trong pipeline.
Nếu secret đã bị commit
Thực hiện theo thứ tự:
Thu hồi credential cũ.
Tạo credential mới.
Cập nhật ứng dụng.
Kiểm tra log sử dụng bất thường.
Xóa giá trị khỏi lịch sử repository khi cần.
Thêm rule chặn secret trước commit.
Ghi nhận sự cố và phạm vi ảnh hưởng.
Chỉ xóa dòng code là chưa đủ vì secret có thể vẫn tồn tại trong lịch sử Git.
Điều kiện hoàn thành
Không có secret trong code và frontend.
Production dùng credential riêng.
Secret có thể được xoay vòng.
Quyền truy cập secret theo nguyên tắc tối thiểu.
Pipeline chặn credential mới bị commit.
Doanh nghiệp nên tham khảo thêm báo cáo State of Secrets Sprawl để đánh giá quy mô vấn đề secret phân tán.
3. Bảo vệ tất cả API tại backend
Không dùng việc ẩn nút hoặc khóa route phía client làm lớp bảo vệ chính.
Mỗi API nhạy cảm phải tự kiểm tra:
người gọi đã xác thực chưa;
token hoặc session còn hiệu lực không;
tài khoản có bị khóa không;
người dùng có quyền gọi chức năng không;
request có thuộc đúng tenant không;
hành động có cần xác thực lại không.
OWASP khuyến nghị mọi tài nguyên không được xác định là public phải yêu cầu xác thực, đồng thời các biện pháp xác thực phải được thực thi trên hệ thống đáng tin cậy.
Phân loại endpoint
Nên phân API thành:
public;
authenticated;
privileged;
internal;
service-to-service.
Mỗi nhóm có middleware và policy rõ ràng.
Không để từng developer hoặc từng đoạn code AI tự quyết định cách kiểm tra xác thực khác nhau.
Kiểm tra token và session
Xác minh:
thời hạn access token;
refresh token;
token revocation;
logout;
đổi mật khẩu;
khóa tài khoản;
chữ ký token;
issuer;
audience;
chống reuse khi cần.
Đối với session cookie, kiểm tra:
Secure;
HttpOnly;
SameSite;
domain;
path;
thời hạn;
cơ chế CSRF phù hợp.
Cách test
Gửi request trong các trạng thái:
không có token;
token sai chữ ký;
token hết hạn;
token user khác;
tài khoản bị khóa;
session đã logout;
thay HTTP method;
gọi endpoint trực tiếp;
gọi từ origin không được phép.
Điều kiện hoàn thành
API nhạy cảm trả 401 khi chưa xác thực.
Token hết hạn không thể sử dụng.
Logout vô hiệu hóa phiên theo chính sách.
Không có API chỉ được bảo vệ ở frontend.
Cơ chế xác thực được áp dụng tập trung.
Đối với đội ngũ chưa có tài liệu kiểm thử API, có thể tham khảo tài liệu API Security của IPSIP.
4. Kiểm tra authorization trên từng đối tượng và hành động
Backend không chỉ cần biết người dùng đã đăng nhập. Nó phải biết người đó có quyền trên tài nguyên đang được yêu cầu hay không.
Ví dụ:
GET /api/invoices/4832
Backend cần xác minh hóa đơn 4832 thuộc user hoặc tenant hợp lệ.
OWASP API Security Top 10 nhấn mạnh các nhóm lỗi liên quan đến object-level, property-level và function-level authorization.
Những kịch bản bắt buộc kiểm tra
User A đọc dữ liệu User B.
User A sửa dữ liệu User B.
Tenant A truy cập Tenant B.
User thường gọi admin API.
Người dùng tự gửi role: admin.
Người tạo yêu cầu tự phê duyệt.
Tài khoản miễn phí gọi chức năng trả phí.
Người dùng thay file ID để tải file khác.
API export trả dữ liệu vượt phạm vi.
Không tin các trường từ frontend
Không dùng trực tiếp các giá trị sau để xác định quyền:
user_id;
tenant_id;
owner_id;
role;
is_admin;
approved;
price.
User ID, tenant ID và role nên được lấy từ session hoặc token đã xác minh, sau đó đối chiếu với dữ liệu phía server.
Nguyên tắc triển khai
Deny by default.
Kiểm tra quyền ở backend.
Tách quyền đọc, sửa, xóa và phê duyệt.
Dùng policy tập trung.
Ghi audit log.
Kiểm tra quyền ở mỗi bước nghiệp vụ.
Không dùng security through obscurity.
Cách test
Tạo:
user A;
user B;
admin;
tenant A;
tenant B.
Sau đó lặp lại cùng request và thay đổi ID trong:
URL;
query string;
request body;
header;
GraphQL variable;
tên file;
đường dẫn tải xuống.
Điều kiện hoàn thành
User không truy cập được tài nguyên ngoài quyền.
Tenant được cô lập.
User thường không gọi được chức năng admin.
Mọi hành động đặc quyền có kiểm tra tại backend.
Có test tự động cho các trường hợp sai quyền.
5. Validate dữ liệu tại server và bảo vệ file upload
Mọi dữ liệu từ trình duyệt, mobile app, webhook, API bên thứ ba và mô hình AI đều phải được xem là không đáng tin cậy.
OWASP khuyến nghị server-side validation, allowlist validation, output encoding theo ngữ cảnh và parameterized query.
Kiểm tra đầu vào
Tại backend:
kiểm tra kiểu dữ liệu;
giới hạn độ dài;
giới hạn khoảng giá trị;
sử dụng enum;
từ chối field không được định nghĩa;
chuẩn hóa dữ liệu;
sử dụng schema validation;
kiểm tra cấu trúc JSON;
giới hạn kích thước request;
dùng parameterized query.
Không nối trực tiếp input vào:
SQL;
NoSQL query;
shell command;
HTML;
template;
đường dẫn file;
URL gọi nội bộ;
truy vấn LDAP.
Bảo vệ file upload
Kiểm tra:
kích thước;
định dạng thực;
phần mở rộng;
MIME type;
tên file;
quyền tải xuống;
khả năng thực thi;
malware;
đường dẫn lưu trữ.
Nên:
đổi tên file;
lưu ngoài web root;
dùng object storage private;
tạo URL tải xuống có thời hạn;
không tin MIME type do trình duyệt gửi;
chặn path traversal;
không phục vụ file dưới quyền thực thi.
Cách test
Thử gửi:
trường bị thiếu;
field ngoài schema;
chuỗi rất dài;
số âm;
số vượt ngưỡng;
HTML và JavaScript;
ký tự truy vấn;
file đổi phần mở rộng;
file lớn;
filename chứa ../;
request có field trùng lặp.
Điều kiện hoàn thành
Backend từ chối dữ liệu sai.
Database query không nối chuỗi từ input.
Response được encode theo ngữ cảnh.
File upload không thể thực thi.
Người dùng chỉ tải được file thuộc quyền.
6. Xác minh dependency do AI đề xuất
Không cài package chỉ vì AI đưa ra lệnh cài đặt.
Trước khi thêm dependency, kiểm tra:
package có tồn tại không;
tên có chính xác không;
publisher là ai;
repository chính thức;
lần cập nhật gần nhất;
lịch sử phát hành;
lỗ hổng đã biết;
dependency con;
license;
install script.
Quy trình đề xuất
Kiểm tra registry chính thức.
Đối chiếu repository.
Xem maintainer.
Kiểm tra advisory và CVE.
Xác định package có thực sự cần thiết không.
Chốt phiên bản bằng lockfile.
Quét dependency trong CI/CD.
Test trước khi cập nhật production.
Công cụ có thể sử dụng
npm audit;
pip-audit;
Dependabot;
Renovate;
OWASP Dependency-Check;
Trivy;
Grype;
công cụ SCA khác.
Không tự động merge mọi bản cập nhật
Bot cập nhật dependency giúp phát hiện phiên bản mới, nhưng không nên tự động merge tất cả thay đổi vào production.
Cần kiểm tra:
breaking change;
maintainer mới;
script mới;
dependency mới;
checksum;
quyền truy cập;
kết quả test.
Điều kiện hoàn thành
Không có package không rõ nguồn gốc.
Lockfile được commit.
Lỗ hổng Critical và High đã được xử lý.
Pipeline theo dõi CVE mới.
Dependency không cần thiết đã bị loại bỏ.
Xem thêm bài chuỗi cung ứng phần mềm bị tấn công để hiểu vì sao dependency cần được quản trị như một phần của bề mặt tấn công.
7. Chạy SAST, SCA và Secret Scanning trên Pull Request
Không chờ đến ngày go-live mới quét code.
Các kiểm tra cơ bản nên chạy trên mỗi pull request.
SAST hỗ trợ tìm gì?
Static Application Security Testing có thể tìm:
hàm nguy hiểm;
một số mẫu injection;
hardcoded credential;
mã hóa yếu;
cấu hình không an toàn;
deserialization nguy hiểm;
xử lý input đáng ngờ.
Công cụ có thể gồm:
Semgrep;
CodeQL;
SonarQube;
scanner phù hợp với ngôn ngữ dự án.
SCA hỗ trợ tìm gì?
Software Composition Analysis kiểm tra:
CVE trong dependency;
package lỗi thời;
transitive dependency;
license;
nguồn gốc thành phần.
Thiết lập quality gate
Có thể áp dụng:
Critical: chặn merge;
High: chặn merge hoặc yêu cầu phê duyệt;
Secret thật: chặn ngay;
False positive: phải có lý do và thời hạn ngoại lệ;
Medium: đưa vào backlog với SLA.
Scanner không phải chứng nhận an toàn
Repository không có cảnh báo vẫn có thể tồn tại:
lỗi phân quyền;
business logic flaw;
tenant isolation failure;
cấu hình cloud sai;
race condition;
endpoint không được kiểm kê;
artifact bị đóng gói nhầm.
Nghiên cứu VibeGuard cho thấy source map exposure, packaging drift và artifact hygiene có thể không được bao phủ đầy đủ bởi công cụ truyền thống.
Điều kiện hoàn thành
Mọi pull request được quét.
Cảnh báo nghiêm trọng có owner.
Ngoại lệ được ghi nhận.
Pipeline chặn secret.
Kết quả được lưu để theo dõi xu hướng.
IPSIP có dịch vụ quét lỗ hổng bảo mật website dành cho doanh nghiệp cần đánh giá bề mặt tấn công và các lỗi kỹ thuật phổ biến.
8. Kiểm thử website đang chạy và kiểm thử API
SAST phân tích code. Kiểm thử động đánh giá ứng dụng đang hoạt động trong môi trường thực tế.
Cả hai cần được kết hợp.
DAST có thể hỗ trợ phát hiện
endpoint bị lộ;
security header thiếu;
cookie sai cấu hình;
một số lỗi injection;
stack trace;
file công khai;
cấu hình web server không an toàn.
Công cụ có thể gồm:
OWASP ZAP;
Burp Suite;
scanner thương mại phù hợp.
API cần được test ngoài happy path
Với mỗi API quan trọng, thử:
bỏ token;
token hết hạn;
token user khác;
thay object ID;
thêm field không mong muốn;
thay HTTP method;
thay content type;
gửi request lớn;
gửi request liên tục;
replay giao dịch;
sửa giá tiền;
gọi admin API bằng user thường;
truy cập chéo tenant.
Đặt câu hỏi ngược
Không chỉ kiểm tra:
Người dùng làm đúng quy trình thì chức năng có chạy không?
Cần kiểm tra:
Có thể bỏ qua bước nào không?
Có thể gọi bước cuối trước bước đầu không?
Có thể thực hiện giao dịch hai lần không?
Có thể thay dữ liệu trong request không?
Có thể sử dụng tài khoản khác không?
Có thể gửi nhiều request đồng thời không?
Có thể dùng token cũ sau logout không?
Điều kiện hoàn thành
Không có API nhạy cảm truy cập được khi sai quyền.
Không lộ stack trace hoặc secret.
Rate limiting hoạt động.
Lỗi nghiêm trọng đã được xử lý.
Các luồng nghiệp vụ chính được test thủ công.
Đọc thêm tài liệu API Security và bài rủi ro bảo mật API đối với ngành tài chính.
9. Giới hạn quyền AI coding agent và hardening production
Hai khu vực này thường bị tách rời nhưng nên được kiểm tra cùng nhau: agent được quyền làm gì và sản phẩm cuối cùng được triển khai như thế nào.
Giới hạn AI coding agent
Agent phát triển không nên có quyền mặc định tới:
production database;
cloud administrator;
production secret;
hệ thống thanh toán thật;
dữ liệu khách hàng;
email account chính;
hệ thống nội bộ không liên quan.
Nên:
chạy agent trong sandbox;
tách development và production;
ưu tiên read-only;
yêu cầu phê duyệt cho lệnh nhạy cảm;
giới hạn outbound network;
allowlist tool;
review MCP server;
dùng credential có thời hạn;
ghi audit log;
không cho agent tự deploy production.
IPSIP đã tổng hợp các rủi ro liên quan trong:
Hardening production
HTTPS và cookie
Bắt buộc HTTPS.
Redirect HTTP sang HTTPS.
Cấu hình HSTS khi phù hợp.
Cookie có Secure.
Session cookie có HttpOnly.
SameSite phù hợp.
CORS
Không cho phép mọi origin với API nhạy cảm nếu không có lý do rõ ràng.
Chỉ allowlist các origin cần thiết.
Database và storage
Không mở database công khai.
Giới hạn kết nối theo mạng và danh tính.
Storage private mặc định.
Không dùng admin credential cho ứng dụng.
Mã hóa backup.
Thử khôi phục backup.
Bật access log.
Debug và error
Tắt debug mode.
Không trả stack trace.
Không làm lộ source map ngoài ý muốn.
Không hiển thị query hoặc đường dẫn nội bộ.
Tách thông báo người dùng và log kỹ thuật.
Không ghi token, password hoặc dữ liệu nhạy cảm vào log.
Monitoring
Cảnh báo khi:
đăng nhập sai tăng đột biến;
xuất hiện nhiều lỗi authorization;
role bị thay đổi;
dữ liệu được export số lượng lớn;
admin endpoint được gọi bất thường;
credential được dùng từ vị trí lạ;
giao dịch hoặc thao tác xóa tăng bất thường.
Điều kiện hoàn thành
Agent không truy cập production secret.
Hành động nguy hiểm cần phê duyệt.
Database và storage không public.
Debug đã tắt.
Có log và cảnh báo.
Backup đã được thử khôi phục.
Đối với ứng dụng trên cloud, xem thêm hướng dẫn toàn diện cách bảo mật hạ tầng đám mây.
10. Pentest trước Production và Retest sau khắc phục
Scanner tự động phù hợp để phát hiện nhiều lỗi kỹ thuật. Tuy nhiên, công cụ thường không hiểu đầy đủ quy tắc kinh doanh.
Ví dụ:
người tạo yêu cầu không được tự phê duyệt;
mã giảm giá chỉ được dùng một lần;
tenant A không được đọc dữ liệu tenant B;
hoàn tiền không được thực hiện hai lần;
tài khoản trial không dùng tính năng trả phí;
nhân viên hỗ trợ không được đổi chủ tài khoản;
AI agent không được gửi dữ liệu khách hàng ra ngoài.
Đây là những tình huống cần người kiểm thử hiểu kiến trúc, dữ liệu và logic vận hành.
Khi nào cần pentest?
Ưu tiên pentest nếu website:
lưu dữ liệu cá nhân;
xử lý thanh toán;
có nhiều tenant;
có nhiều vai trò;
có admin panel;
cung cấp API;
cho phép upload file;
tích hợp hệ thống nội bộ;
có AI agent;
chuẩn bị bán cho khách hàng doanh nghiệp;
vừa thay đổi authentication hoặc authorization;
được xây nhanh nhưng chưa có security review độc lập.
Phạm vi pentest đề xuất
Web application.
Backend API.
Authentication.
Authorization.
Session management.
Tenant isolation.
File upload.
Business logic.
Cloud exposure.
AI feature.
Prompt injection.
Cấu hình production.
Sau khi nhận báo cáo
Xác định mức độ rủi ro.
Chỉ định người phụ trách.
Khắc phục nguyên nhân gốc.
Kiểm tra các chức năng liên quan.
Retest.
Bổ sung test vào CI/CD.
Ghi nhận rủi ro còn lại.
IPSIP đã có các tài liệu hướng dẫn:
Quy trình bảo mật website Vibe Coding theo từng giai đoạn
Trước khi AI viết code
Phân loại dữ liệu.
Xác định role.
Viết policy phân quyền.
Xác định trust boundary.
Chọn dependency được phép.
Tách môi trường.
Giới hạn agent.
Viết negative test.
Trong quá trình phát triển
Không dùng secret thật.
Review code rủi ro cao.
Validate ở backend.
Dùng authorization policy chung.
Viết test sai quyền.
Commit lockfile.
Ghi nhận thay đổi kiến trúc.
Trước khi merge
Unit test.
SAST.
SCA.
Secret scanning.
Review authentication.
Review authorization.
Kiểm tra package mới.
Phê duyệt thay đổi nhạy cảm.
Trên staging
Chạy DAST.
Kiểm thử API.
Test truy cập chéo.
Test nhiều tenant.
Test file upload.
Kiểm tra cookie.
Kiểm tra CORS.
Kiểm tra error leakage.
Trước production
Tạo hoặc xoay secret production.
Xác minh database private.
Xác minh storage private.
Tắt debug.
Bật monitoring.
Kiểm tra backup.
Pentest.
Retest sau khi sửa.
Sau khi phát hành
Theo dõi log.
Quét dependency định kỳ.
Xử lý CVE mới.
Review quyền agent.
Kiểm tra thay đổi do AI tạo.
Pentest lại sau thay đổi lớn.
Duy trì kế hoạch ứng phó sự cố.
Checklist trước Production
Secret và dữ liệu
Không có secret trong code.
Frontend không chứa API key bí mật.
Credential giữa các môi trường được tách.
Dữ liệu nhạy cảm không xuất hiện trong log.
Backup đã được kiểm tra.
Authentication và authorization
Mọi API nhạy cảm yêu cầu xác thực.
User A không truy cập dữ liệu User B.
Tenant A không truy cập Tenant B.
User thường không gọi được admin API.
Token và session có thời hạn.
Logout và thu hồi token hoạt động.
Code và dependency
SAST đã chạy.
SCA đã chạy.
Secret scanning đã chạy.
Package mới đã được xác minh.
Không còn lỗi Critical hoặc High chưa xử lý.
Ứng dụng đang chạy
DAST đã chạy trên staging.
API đã được test ngoài happy path.
File upload được kiểm soát.
HTTPS được bắt buộc.
Cookie được cấu hình an toàn.
CORS chỉ allowlist origin cần thiết.
Debug mode đã tắt.
AI coding agent
Agent không có production credential.
Lệnh nguy hiểm cần phê duyệt.
MCP server đã được review.
Hoạt động agent có log.
Agent không thể tự deploy production.
Kiểm thử độc lập
Hệ thống đã được pentest nếu có dữ liệu hoặc logic quan trọng.
Lỗ hổng nghiêm trọng đã được sửa.
Bản sửa đã được retest.
Rủi ro còn lại được phê duyệt.
Khi nào quét lỗ hổng chưa đủ?
Quét lỗ hổng chưa đủ khi vấn đề phụ thuộc vào:
quyền truy cập;
ngữ cảnh doanh nghiệp;
trình tự nghiệp vụ;
trạng thái giao dịch;
mối quan hệ giữa nhiều tài khoản;
dữ liệu của nhiều tenant;
quyền của AI agent.
Ví dụ:
bỏ qua bước phê duyệt;
thay đổi giá;
tái sử dụng mã giảm giá;
hoàn tiền hai lần;
chiếm quyền tài khoản qua luồng hỗ trợ;
tải file của user khác;
truy cập dữ liệu tenant khác;
yêu cầu agent thực hiện hành động ngoài phạm vi.
Trong trường hợp này, doanh nghiệp cần kiểm thử xâm nhập có yếu tố thủ công.
Xem thêm bài phân biệt pentest và quét lỗ hổng bảo mật.
Giải pháp bảo mật cho website vibe coding không nằm ở một prompt hoặc một công cụ quét duy nhất.
Một quy trình phù hợp cần kết hợp:
Viết yêu cầu bảo mật trước khi tạo code.
Quản lý secret.
Xác thực tại backend.
Kiểm tra authorization.
Validate dữ liệu.
Quản trị dependency.
SAST, SCA và secret scanning.
DAST và API security testing.
Giới hạn AI agent và hardening production.
Pentest và retest.
AI có thể rút ngắn thời gian tạo sản phẩm. Nhưng trước khi website xử lý dữ liệu thật hoặc phục vụ khách hàng, mức độ an toàn cần được chứng minh bằng các kiểm soát và kết quả kiểm thử có thể xác minh.
Doanh nghiệp cần đánh giá website trước production có thể sử dụng dịch vụ Pentest của IPSIP hoặc bắt đầu bằng dịch vụ quét lỗ hổng bảo mật website để xác định các điểm yếu cần ưu tiên xử lý.
------------
Câu hỏi thường gặp
Có thể dùng AI để review code do AI tạo không?
Có thể dùng AI như một lớp hỗ trợ. Tuy nhiên, không nên coi kết quả đó là bằng chứng duy nhất rằng website an toàn.
Công cụ nào phù hợp để kiểm tra web vibe coding?
Nên kết hợp secret scanner, SAST, SCA, DAST, API testing và kiểm thử thủ công thay vì phụ thuộc một công cụ.
SAST có đủ không?
Không. SAST không đánh giá đầy đủ ứng dụng đang chạy, cấu hình cloud, quyền truy cập và business logic.
Cần kiểm tra lại sau mỗi lần AI sửa code không?
Không nhất thiết pentest toàn bộ sau mọi thay đổi nhỏ, nhưng CI/CD phải chạy kiểm tra tự động. Thay đổi lớn liên quan đến đăng nhập, phân quyền, API, thanh toán hoặc hạ tầng cần được đánh giá lại.
Website nào bắt buộc nên pentest?
Các website có dữ liệu nhạy cảm, thanh toán, nhiều vai trò, API, admin panel, multi-tenant hoặc tích hợp hệ thống nội bộ nên được ưu tiên pentest.
-------------------
Nguồn tham khảo
OWASP Secure Coding Practices Checklist: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/02-checklist/
OWASP API Security Top 10 – 2023: https://owasp.org/API-Security/editions/2023/en/0x11-t10/
OWASP Secure Code Review Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html
OWASP Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
OWASP Input Validation Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
OWASP Authorization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
OWASP File Upload Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html
OWASP REST Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
OWASP Vulnerable Dependency Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html
NIST SP 800-218 – Secure Software Development Framework: https://csrc.nist.gov/pubs/sp/800/218/final
Bình luận