קוד שנכתב עם AI: מה בודקים לפני שמעלים אותו לאתר

כלי AI לכתיבת קוד טובים במשהו שקשה להעריך את ערכו: הם מביאים אתכם מרעיון לקוד שרץ בכמה דקות. הם גם טובים במשהו שקשה להעריך את הסכנה שבו: הקוד הזה נראה גמור. יש לו שמות משתנים נכונים, הערות, ולעיתים אפילו בדיקות. מה שחסר לא נראה בקריאה מהירה, ולכן צריך רשימה.

הרשימה הזאת לא מניחה שהכלי טועה יותר מאדם. היא מניחה שהוא טועה אחרת: אדם שכותב קוד אבטחה חושב על התוקף תוך כדי; המודל חושב על הדוגמה שביקשתם.

הכשלים שחוזרים

1. קלט שמגיע ישר לשאילתה או לפלט

הבקשה הייתה ״תביא את המאמר לפי slug״, והקוד מרכיב מחרוזת SQL עם ה-slug בתוכה, או מדפיס כותרת ל-HTML בלי בריחה. בהדגמה זה עובד. עם slug כמו ' OR 1=1 זה לא. הבדיקה: כל שאילתה עם prepared statements, כל פלט דרך פונקציית escaping. אם אתם לא רואים ? או placeholders בשאילתות, יש בעיה.

2. תלות שלא קיימת או לא כפי שתוארה

מודלים ממציאים לפעמים פונקציה בספרייה אמיתית, או ספרייה שלמה בשם סביר. ב-PHP זה נראה כמו use Vendor\Package\Thing שלא מותקן, או קריאה לפונקציה שקיימת רק בגרסה אחרת. הבדיקה: להריץ את הקוד, לא לקרוא אותו. ואם מותקנת תלות חדשה, לבדוק מי מתחזק אותה ומתי עודכנה לאחרונה.

3. סודות בקוד

״תחבר למסד״ מתורגם בקלות ל-new PDO('mysql:…', 'root', 'password') בתוך הקובץ. בהדגמה נוח. ב-git ציבורי זה דליפה. הבדיקה: חיפוש של סיסמאות, מפתחות ו-DSN בקבצי הקוד; כל ערך כזה צריך לשבת בקובץ הגדרות מחוץ לשורש הציבורי, ולא במאגר.

4. הצלחה בלי אימות

טופס קשר ש״שולח״ ומציג ״נשלח בהצלחה״ בלי לבדוק את ערך ההחזרה של הפונקציה; או שמציג הצלחה גם כשהשמירה למסד נכשלה. זה לא באג של אבטחה, אלא של אמת: המשתמש חושב שפנה, ואף אחד לא קיבל. הבדיקה: לגרום לכישלון בכוונה (לנתק את המסד, לשנות כתובת דוא״ל ללא תקינה) ולראות מה מוצג.

5. מקרי קצה שלא היו בפרומפט

כותרת ריקה, קובץ של 50 מגה, תו עברי ב-URL, תאריך עתידי, בקשה כפולה. המודל פתר את המקרה שתיארתם. הבדיקה: לכתוב רשימה של עשרה קלטים מוזרים ולהזין אותם. זה לוקח עשר דקות ומוצא רוב הבעיות.

6. הרשאות שלא נבדקו

פעולת מחיקה שזמינה לכל מי שמחובר, או API שלא בודק מי שולח. ברוב הכלים, אם לא ביקשתם במפורש בדיקת הרשאה, היא לא תהיה שם. הבדיקה: לכל נקודת כניסה, לשאול ״מי רשאי להגיע לכאן, ואיפה זה נבדק״.

למה זה קורה, ולמה זה יישאר

המודל מייצר את הקוד הסביר ביותר בהינתן הבקשה. רוב הקוד שהוא למד ממנו הוא קוד הדגמה, מדריכים ותשובות בפורומים, ובקוד כזה מדלגים על סינון, הרשאות וטיפול בשגיאות כדי להתמקד ברעיון. הכלים משתפרים, ובקשה מפורשת (״עם prepared statements, עם בדיקת CSRF, עם טיפול בכישלון״) עוזרת הרבה. אבל הנטייה הבסיסית, לכתוב את המקרה המרכזי ולא את הגבולות, היא תכונה של איך הם למדו.

רשימת בדיקות לפני העלאה

1. הרצה מקומית מלאה, כולל המסלולים שנכשלים.
2. חיפוש בקוד אחר שרשור מחרוזות לשאילתות, אחר echo של משתנים בלי escaping, ואחר סודות.
3. אימות שכל תלות קיימת, מתוחזקת, ובגרסה שמצוינת.
4. עשרה קלטים מוזרים לכל טופס ונקודת קצה.
5. בדיקת הרשאות לכל פעולה שמשנה משהו.
6. קריאה של הקוד על ידי מי שיתחזק אותו, גם אם זה אתם בעוד שנה. אם הוא לא מובן בלי המודל, הוא לא גמור.

והנקודה האחרונה היא אולי החשובה: קוד שהבנתם רק דרך הסבר של המודל הוא קוד שתצטרכו את המודל כדי לתקן. זה בסדר כבחירה מודעת. זה פחות בסדר כהפתעה בשלוש בלילה.