Reviewing AI-Generated Code for Vulnerabilities

Một dòng code do AI sinh ra có thể chạy hoàn hảo trong demo và vẫn là cánh cửa mở toang cho kẻ tấn công — vấn đề là công cụ review mặc định của bạn thường không phát hiện ra điều đó.

Vì sao code do AI sinh ra thường có lỗ hổng bảo mật mang tính hệ thống

Nhiều kỹ sư tin rằng code do AI viết "sạch" hơn code con người viết vội, vì nó luôn được format đẹp, có comment đầy đủ, biến được đặt tên rõ ràng. Nhưng "trông sạch" và "an toàn" là hai chuyện hoàn toàn khác nhau. Có ít nhất năm lý do khiến các AI coding assistant (trợ lý lập trình AI) — kể cả những model mạnh nhất hiện nay — có xu hướng sinh ra lỗ hổng bảo mật theo những pattern (khuôn mẫu) lặp lại, dễ đoán.

Thứ nhất, model được huấn luyện trên một lượng khổng lồ code công khai — GitHub, Stack Overflow, tutorial, blog. Phần lớn code đó được viết để minh hoạ ý tưởng, không phải để chạy production. Một câu trả lời Stack Overflow năm 2013 nối chuỗi SQL trực tiếp vẫn được upvote vì nó "giải quyết được vấn đề", và model học được rằng đó là cách làm phổ biến, không phân biệt được đó là ví dụ giáo dục hay code production-ready.

Thứ hai, mục tiêu tối ưu của các model này khi sinh code là "trông đúng và chạy được", không phải "an toàn". Loss function và các vòng RLHF (học tăng cường từ phản hồi con người) thưởng cho việc code compile, test pass, output đúng — không có tín hiệu trực tiếp nào thưởng cho việc chọn bcrypt thay vì MD5, hay validate input trước khi query database. Bảo mật là một thuộc tính "vô hình" đối với đa số benchmark đánh giá coding model.

Thứ ba, AI không có full context về threat model (mô hình mối đe doạ) của ứng dụng bạn đang xây. Nó không biết endpoint này có bị public internet gọi tới không, dữ liệu này có phải PII (thông tin định danh cá nhân) không, hệ thống có cần multi-tenant isolation hay không. Thiếu ngữ cảnh, nó mặc định implement theo cách generic nhất — và generic thường đồng nghĩa với ít kiểm soát truy cập nhất.

Thứ tư, khi đứng giữa nhiều cách giải quyết một bài toán, AI có xu hướng chọn giải pháp đơn giản nhất, ít dòng code nhất, dễ giải thích nhất — và giải pháp đơn giản gần như luôn là giải pháp kém an toàn hơn. String concatenation cho SQL đơn giản hơn parameterized query. Tắt CSRF (Cross-Site Request Forgery — giả mạo yêu cầu chéo trang) để test nhanh đơn giản hơn là config đúng token. Access-Control-Allow-Origin: * đơn giản hơn whitelist domain.

Thứ năm, có yếu tố "sycophancy" (xu hướng chiều lòng người dùng) — AI được tối ưu để tạo cảm giác hữu ích, phản hồi nhanh, "code chạy được" ngay lập tức. Nếu bạn hỏi "viết cho tôi API login", nó ưu tiên đưa ra thứ chạy được trong 10 giây, thay vì dừng lại hỏi bạn về rate limiting hay account lockout policy. Cuối cùng là "ảo giác về uy quyền" (illusion of authority): code AI viết ra trông tự tin, có docstring, có type hint, khiến reviewer con người vô thức hạ thấp mức độ soi xét — giống hiệu ứng "trông chuyên nghiệp thì chắc đúng".

Mẹo: Đừng đánh giá độ an toàn của code qua việc nó "trông gọn gàng" — hãy tự hỏi mỗi lần review AI code: "Nếu tôi là attacker, tôi sẽ tấn công vào chỗ nào của đoạn này?" trước khi đọc tiếp phần còn lại.

Các pattern OWASP Top 10 mà AI thường vô tình đưa vào code

Danh sách OWASP Top 10 là bản đồ rủi ro bảo mật ứng dụng web được công nhận rộng rãi nhất. Dưới đây là cách các rủi ro này thường xuất hiện cụ thể trong code do AI sinh ra, kèm ví dụ trước/sau.

1. Broken Access Control (Kiểm soát truy cập bị phá vỡ)

AI thường viết đúng logic nghiệp vụ nhưng quên hoàn toàn bước kiểm tra quyền, đặc biệt với các endpoint được yêu cầu "nhanh gọn":

// AI-generated — thiếu kiểm tra quyền sở hữu
app.get('/api/orders/:id', authenticate, async (req, res) => {
  const order = await Order.findById(req.params.id);
  res.json(order);
});

// Fixed — kiểm tra order thuộc về user hiện tại
app.get('/api/orders/:id', authenticate, async (req, res) => {
  const order = await Order.findById(req.params.id);
  if (!order || order.userId !== req.user.id) {
    return res.status(404).json({ error: 'Not found' });
  }
  res.json(order);
});

2. Cryptographic Failures (Lỗi mật mã học)

import hashlib
API_SECRET = "sk_live_49fk29fj29fj"

def hash_password(password):
    return hashlib.md5(password.encode()).hexdigest()

import bcrypt
import os
API_SECRET = os.environ["API_SECRET"]

def hash_password(password):
    return bcrypt.hashpw(password.encode(), bcrypt.gensalt())

3. Injection

def get_user(username):
    query = f"SELECT * FROM users WHERE username = '{username}'"
    return db.execute(query)

def get_user(username):
    query = "SELECT * FROM users WHERE username = %s"
    return db.execute(query, (username,))

4. Insecure Design

Đây là lỗi ở tầng thiết kế, khó thấy qua vài dòng code. Ví dụ AI viết chức năng "quên mật khẩu" gửi mật khẩu cũ dạng plaintext qua email thay vì token reset có hạn dùng — logic chạy đúng, nhưng thiết kế đã sai từ gốc vì hệ thống không nên bao giờ lưu hoặc gửi mật khẩu dạng đọc được.

5. Security Misconfiguration

// AI-generated — CORS mở toàn bộ, debug mode bật
app.use(cors({ origin: '*' }));
app.set('env', 'development');
app.use((err, req, res, next) => {
  res.status(500).json({ stack: err.stack, query: err.query });
});

// Fixed — whitelist origin, ẩn chi tiết lỗi
app.use(cors({ origin: ['https://app.example.com'] }));
app.use((err, req, res, next) => {
  console.error(err);
  res.status(500).json({ error: 'Internal server error' });
});

6. Vulnerable and Outdated Components

AI training data có độ trễ, nên nó hay gợi ý cài package theo phiên bản phổ biến trong dữ liệu huấn luyện — có thể là bản đã có CVE (Common Vulnerabilities and Exposures — mã định danh lỗ hổng công khai) được công bố từ lâu. Luôn tự chạy npm audit, pip-audit sau khi AI thêm dependency, đừng tin số version nó gõ ra.

7. Identification and Authentication Failures

// AI-generated — không rate limit, session cố định
app.post('/login', async (req, res) => {
  const user = await verifyCredentials(req.body.email, req.body.password);
  if (user) req.session.userId = user.id;
  res.json({ success: !!user });
});

// Fixed — rate limit + regenerate session
app.post('/login', loginRateLimiter, async (req, res) => {
  const user = await verifyCredentials(req.body.email, req.body.password);
  if (user) {
    req.session.regenerate(() => {
      req.session.userId = user.id;
      res.json({ success: true });
    });
  } else {
    res.status(401).json({ success: false });
  }
});

8. Software and Data Integrity Failures

import pickle
data = pickle.loads(request.data)

import json
data = json.loads(request.data)
validate_schema(data, schema)

9. Security Logging and Monitoring Failures

// AI-generated — log luôn cả secret và PII
console.log(`Login attempt: ${email} / ${password}`);

// Fixed — log sự kiện, không log dữ liệu nhạy cảm
logger.info('Login attempt', { email, timestamp: Date.now() });

10. SSRF (Server-Side Request Forgery)

// AI-generated — fetch URL do user cung cấp không kiểm soát
app.post('/fetch-preview', async (req, res) => {
  const response = await fetch(req.body.url);
  res.json(await response.json());
});

// Fixed — whitelist domain, chặn IP nội bộ
app.post('/fetch-preview', async (req, res) => {
  const url = new URL(req.body.url);
  if (!ALLOWED_HOSTS.includes(url.hostname) || isPrivateIp(url.hostname)) {
    return res.status(400).json({ error: 'URL not allowed' });
  }
  const response = await fetch(url.toString());
  res.json(await response.json());
});

Mẹo: In một bản OWASP Top 10 dán cạnh màn hình (hoặc pin lên Slack channel của team) — khi review PR có code AI sinh, lướt qua từng mục một lần, đừng chỉ dựa vào trí nhớ.

Cách viết prompt review tập trung vào bảo mật

Bạn có thể tận dụng chính AI để review code AI đã viết — nhưng phải hỏi đúng cách. Prompt chung chung như "review code này" gần như luôn cho ra nhận xét về style, đặt tên biến, không đào sâu bảo mật. Dưới đây là ba prompt bạn có thể copy-paste gần như nguyên văn.

Prompt 1 — Review diff theo OWASP Top 10:

You are a senior application security engineer. Review the following diff
specifically for security vulnerabilities, not style or performance.

For each finding, output in this exact format:
- Severity: Critical / High / Medium / Low
- OWASP category: (e.g. A01 Broken Access Control)
- File and line: 
- Description: what is wrong and why it is exploitable
- Fix: concrete code suggestion

Do not comment on anything that is not a security issue. If there are no
issues, say so explicitly rather than inventing minor ones.

Diff:
<paste diff here>

Prompt 2 — Buộc AI đóng vai attacker:

Adopt the mindset of a malicious attacker who has read-only access to this
codebase and wants to compromise it. Given the code below, describe:
1. The top 3 most realistic attack paths you would try first
2. The exact input or request you would send to exploit each one
3. What data or access you would gain if successful

Be specific with request payloads and endpoint names. Do not soften
findings out of politeness.

Code:
<paste code here>

Prompt 3 — Kiểm tra authorization trên endpoint mới:

List every new or modified API endpoint in this diff. For each endpoint,
answer explicitly:
- Does it require authentication? Where is that enforced?
- Does it verify the authenticated user is authorized for the specific
  resource being accessed (not just "logged in")?
- What happens if an authenticated user passes another user's resource ID?

If any answer is "not verified" or "unclear", flag it as a finding.

Diff:
<paste diff here>

Điểm chung của cả ba prompt: chúng ép AI trả lời theo cấu trúc cụ thể (severity, vị trí, fix), giới hạn phạm vi chỉ vào bảo mật, và yêu cầu tường minh thay vì để AI tự chọn mức độ chi tiết. Nếu không ép format, AI có xu hướng trả lời chung chung kiểu "code trông ổn, có thể cân nhắc thêm validation" — vô nghĩa cho việc audit.

Mẹo: Luôn chạy ít nhất 2 trong 3 prompt trên cho mỗi PR quan trọng — một prompt theo checklist (OWASP) và một prompt theo tư duy tấn công (attacker mindset) thường phát hiện các nhóm lỗi khác nhau, bổ sung cho nhau.

Các pattern code cần luôn tự tay kiểm tra, bất kể AI review nói gì

AI review — dù là do chính AI khác thực hiện — vẫn có thể bỏ sót hoặc bị "thuyết phục" rằng code ổn nếu comment hoặc tên hàm gây hiểu lầm. Có một số pattern nên trở thành phản xạ kiểm tra thủ công, không bao giờ giao hoàn toàn cho tool:

Raw SQL string interpolation: bất kỳ query nào build bằng f-string, template literal, hay + nối chuỗi có chứa input người dùng.
Route thiếu middleware xác thực/phân quyền: so sánh route mới với các route tương tự đã có — nếu route cũ có authenticate, authorize('admin') mà route mới không có, đặt câu hỏi.
Secret/key hardcode trong code: API key, connection string, JWT secret nằm trực tiếp trong file thay vì biến môi trường hoặc secret manager.
Linter/security rule bị tắt: các dòng // eslint-disable, # noqa, # nosec mới xuất hiện — AI hay tự tắt rule để "code chạy được" thay vì sửa nguyên nhân.
Exception handling quá rộng, nuốt lỗi: except Exception: pass hoặc catch (e) {} trống — che giấu lỗi bảo mật thay vì xử lý.
Deserialize không an toàn: pickle.loads, yaml.load (không phải safe_load), eval/exec trên dữ liệu từ bên ngoài.
Path traversal trong thao tác file: ghép đường dẫn từ input người dùng mà không validate, ví dụ open(f"./uploads/{filename}").
eval/exec không an toàn: đặc biệt khi input đến từ request hoặc config do người dùng chỉnh.
Thiếu input validation: endpoint nhận JSON body nhưng không có schema validation (Zod, Joi, Pydantic...) trước khi dùng dữ liệu.
CORS wildcard: Access-Control-Allow-Origin: * kết hợp với credentials: true là đặc biệt nguy hiểm.
Thiếu rate limiting: đặc biệt trên endpoint login, reset password, OTP verify.
Random không an toàn cho token: Math.random() hay random.random() dùng để sinh session token, reset token, API key — phải dùng crypto.randomBytes / secrets.token_urlsafe.

Mẹo: Biến danh sách trên thành một grep script chạy trước mỗi lần merge — ví dụ grep -rn "Math.random()\|pickle.loads\|eslint-disable" src/ — phát hiện sớm rẻ hơn nhiều so với review bằng mắt.

Xây dựng checklist bảo mật cho code do AI sinh

Một checklist rời rạc trong đầu mỗi người sẽ không nhất quán giữa các thành viên team. Cách hiệu quả hơn là đóng gói checklist thành một artifact dùng chung — có thể là file markdown trong repo, hoặc một rule file cho chính AI assistant (kiểu CLAUDE.md, .cursor/rules) để nó tự áp dụng ngay khi sinh code, không đợi đến lúc review.

Checklist nên tổ chức theo nhóm rủi ro, không theo thứ tự file hay tính năng, để dễ áp dụng nhất quán cho mọi PR:

## Security Checklist for AI-Assisted PRs

### Authorization
- [ ] Every new/modified endpoint checks authentication
- [ ] Every new/modified endpoint checks resource-level ownership,
      not just "user is logged in"
- [ ] Admin-only actions verify role, not just presence of a token

### Secrets
- [ ] No hardcoded API keys, passwords, or connection strings
- [ ] All secrets read from environment variables or a secret manager
- [ ] .env files are in .gitignore and not committed

### Injection
- [ ] All SQL/NoSQL queries use parameterized queries or an ORM
- [ ] No use of eval/exec on user-supplied input
- [ ] Shell commands do not interpolate raw user input

### Cryptography
- [ ] Passwords hashed with bcrypt/argon2, never MD5/SHA1
- [ ] Tokens generated with a cryptographically secure random source
- [ ] TLS enforced for all external communication

### Logging
- [ ] No passwords, tokens, or PII written to logs
- [ ] Error responses do not leak stack traces to clients

### Dependencies
- [ ] New packages checked against known CVEs (npm audit / pip-audit)
- [ ] No packages added without a stated reason in the PR description

Với các team dùng AI coding assistant hằng ngày, cách tận dụng tốt nhất checklist này là nhúng nó thẳng vào file cấu hình mà assistant đọc mỗi lần (CLAUDE.md, cursor rules, hay system prompt nội bộ), kèm câu lệnh dạng: "Trước khi hoàn thành bất kỳ endpoint mới nào, tự kiểm tra qua Security Checklist ở trên và nêu rõ mục nào đã thoả, mục nào chưa áp dụng được." Việc này chuyển checklist từ công cụ review thụ động thành ràng buộc chủ động ngay tại thời điểm sinh code.

Mẹo: Đừng để checklist chỉ nằm trong đầu team lead — commit nó vào repo dưới dạng file, để nó version-hoá cùng code và mọi thành viên (kể cả người mới) đều thấy ngay từ ngày đầu.

Thực hành: Thực hiện review bảo mật trên code do AI sinh

Hãy cùng đi qua một ví dụ cụ thể. Giả sử bạn yêu cầu AI: "Viết cho tôi một endpoint Express để user cập nhật thông tin profile của họ, lấy dữ liệu theo ID truyền vào." AI trả về đoạn code sau:

// BEFORE — AI-generated, chưa qua review
const express = require('express');
const db = require('./db');
const router = express.Router();

router.put('/users/:id', (req, res) => {
  const { id } = req.params;
  const { name, email, bio } = req.body;

  const query = `UPDATE users SET name='${name}', email='${email}', bio='${bio}' WHERE id=${id}`;
  db.query(query, (err, result) => {
    if (err) return res.status(500).json({ error: err.message });
    res.json({ success: true });
  });
});

module.exports = router;

Bước 1 — Chạy prompt review OWASP (Prompt 1 ở mục trên) trên đoạn diff này. Kết quả điển hình sẽ chỉ ra:

Critical / A03 Injection: name, email, bio, id được nối trực tiếp vào SQL string → SQL injection.
Critical / A01 Broken Access Control: không có middleware xác thực, bất kỳ ai cũng gọi được endpoint, và không kiểm tra id có phải là user đang đăng nhập hay không.
Medium / A09 Logging Failures: err.message trả thẳng về client, có thể lộ chi tiết cấu trúc database.

Bước 2 — Đối chiếu với checklist thủ công ở mục 4: xác nhận thêm là không có input validation (không kiểm tra email có đúng định dạng, bio có giới hạn độ dài).

Bước 3 — Sửa từng finding, ưu tiên theo severity:

// AFTER — đã fix
const express = require('express');
const { z } = require('zod');
const db = require('./db');
const { authenticate } = require('./middleware/auth');
const router = express.Router();

const updateProfileSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email(),
  bio: z.string().max(500).optional(),
});

router.put('/users/:id', authenticate, async (req, res) => {
  const { id } = req.params;

  // Authorization: user chỉ được sửa profile của chính mình
  if (String(req.user.id) !== id) {
    return res.status(403).json({ error: 'Forbidden' });
  }

  // Input validation
  const parsed = updateProfileSchema.safeParse(req.body);
  if (!parsed.success) {
    return res.status(400).json({ error: 'Invalid input' });
  }
  const { name, email, bio } = parsed.data;

  try {
    await db.query(
      'UPDATE users SET name = $1, email = $2, bio = $3 WHERE id = $4',
      [name, email, bio, id]
    );
    res.json({ success: true });
  } catch (err) {
    console.error('Failed to update user profile', { userId: id });
    res.status(500).json({ error: 'Internal server error' });
  }
});

module.exports = router;

Bước 4 — Chạy lại prompt review trên bản fix để xác nhận không còn finding Critical/High nào còn sót — đây là bước hay bị bỏ qua nhưng quan trọng, vì đôi khi fix một lỗi lại vô tình mở ra lỗi khác (ví dụ quên xử lý trường hợp req.user không tồn tại).

Bài tập này chỉ mất khoảng 10-15 phút nhưng thể hiện đầy đủ quy trình: review bằng prompt có cấu trúc, đối chiếu checklist thủ công, sửa theo ưu tiên severity, và verify lại — quy trình này nên là thói quen mặc định cho mọi PR có phần code do AI sinh ra, không chỉ khi "cảm thấy nghi ngờ".

Mẹo: Luôn giữ lại bản "BEFORE" trong lịch sử PR (đừng squash mất) — nó là tài liệu huấn luyện tốt nhất cho thành viên mới trong team về việc AI có thể sai ở đâu.

Những điểm chính

AI coding assistant sinh lỗ hổng bảo mật có hệ thống vì được huấn luyện trên code trung bình, tối ưu cho "chạy được" chứ không phải "an toàn", và thiếu context về threat model của ứng dụng.
Mọi hạng mục trong OWASP Top 10 đều có thể xuất hiện qua code AI sinh — phổ biến nhất là Broken Access Control, Injection, và Security Misconfiguration.
Prompt review chung chung không đủ — cần prompt ép AI trả lời theo cấu trúc severity/vị trí/fix, hoặc đóng vai attacker để tìm ra attack path cụ thể.
Một số pattern (raw SQL, secret hardcode, CORS wildcard, random không an toàn) cần luôn kiểm tra thủ công, không giao phó hoàn toàn cho AI review.
Checklist bảo mật nên được đóng gói thành file dùng chung trong repo, tổ chức theo nhóm rủi ro (authz, secrets, injection, crypto, logging, dependencies).
Nhúng checklist vào rule file của AI assistant (CLAUDE.md, cursor rules) giúp chặn lỗi ngay từ lúc sinh code, thay vì chỉ phát hiện ở bước review.
Quy trình review bảo mật hiệu quả luôn có bước verify lại sau khi fix — vì fix một lỗi đôi khi vô tình tạo ra lỗi mới.