Chegara nazoratchisini (customs officer) tasavvur qiling: u har bir yo'lovchining "men hech narsa olib o'tayotganim yo'q" degan so'ziga ISHONIB, hech kimning chamadonini tekshirmasa — chegara amalda YOPIQ emas, OCHIQ bo'lib qoladi. Yaxshi nazoratchi HAR BIR chamadonni, hatto eng "ishonchli ko'ringan" yo'lovchinikini ham tekshiradi. Xavfsizlikka sezgir kodda ham xuddi shunday: tashqaridan (foydalanuvchidan, tarmoqdan) kelgan HAR QANDAY ma'lumotga "ehtimol yaxshi niyat bilan yuborilgan" deb ishonib bo'lmaydi.

Xavfsizlikka sezgir kodni ko'rib chiqish — oldingi darslardagi "besh toifa"dan farqli, QO'SHIMCHA nazar talab qiladi: bu yerda savol shunchaki "kod to'g'ri ishlaydimi" emas, balki "kimdir bu kodni ATAYLAB, YOMON niyat bilan chalg'itishga urinsa nima bo'ladi?"

func SearchUsers(db *sql.DB, name string) ([]User, error) {
	query := fmt.Sprintf(
		"SELECT id, name FROM users WHERE name LIKE '%%%s%%'",
		name,
	)
	rows, err := db.Query(query)
	// ...
}

Bu kod "baxtli yo'l"da (oddiy ism kiritilganda) to'g'ri ishlaydi. Lekin name — foydalanuvchidan kelgan, TEKSHIRILMAGAN matn, va u to'g'ridan-to'g'ri SQL so'roviga fmt.Sprintf orqali QO'SHILGAN. Agar kimdir name sifatida ' OR '1'='1 kabi maxsus tuzilgan matn yuborsa, bu SQL so'rovining MA'NOSINI butunlay o'zgartirib yuborishi mumkin — bu SQL in'ektsiyasi (SQL injection) deb ataladigan, eng xavfli va eng keng tarqalgan xavfsizlik teshiklaridan biri.

• •Xavfsiz yechim — fmt.Sprintf bilan so'rov QURISH o'rniga, db.Query("SELECT id, name FROM users WHERE name LIKE ?", "%"+name+"%") kabi PARAMETRLANGAN so'rov ishlatish — bu holda namening ICHIDAGI matn HECH QACHON SQL buyrug'i sifatida talqin qilinmaydi, u faqat QIYMAT sifatida ko'riladi
• •Learn database/sql kursida ko'rgan ? (yoki $1) belgisi — aynan shu xavfsizlik uchun mo'ljallangan, va u DEYARLI har doim Sprintf orqali qo'lda so'rov qurishdan afzal
• •Umumiy qoida: agar foydalanuvchi kiritgan matn to'g'ridan-to'g'ri BUYRUQ (SQL, shell buyrug'i, fayl yo'li) ichiga QO'SHILSA, bu deyarli har doim in'ektsiya xavfini keltirib chiqaradi

Xavfsizlikka sezgir kodni ko'rib chiqishda foydali savollar: "bu qiymat QAYERDAN keladi — foydalanuvchidanmi, tashqi API'danmi?" (agar ha bo'lsa, unga ISHONMANG); "bu qiymat qayerga BORADI — SQL so'roviga, fayl yo'liga, shell buyrug'iga?" (agar shunday joyga borsa, u PARAMETRLASHTIRISH yoki TOZALASH orqali himoyalanishi kerak).

Bu turdagi review izohi — Blocking Comments vs. Nitpicks darsidagi ma'noda DEYARLI HAR DOIM to'sib qo'yuvchi (blocking): xavfsizlik teshigi "kelajakda tuzatamiz" deb qoldirilishi mumkin bo'lgan narsa emas, chunki uni ATAYLAB qidirib topadigan tomon (hujumchi) mavjud — bu Technical Debt darsida ko'rgan "eng yomon holatda tizim ishdan chiqadi" toifasiga kiradi.