אבטחה ופרטיות

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

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

חשוב להשתמש תמיד ב-HTTPS, במיוחד בדפים שכוללים טופס. באמצעות HTTPS, הנתונים מוצפנים כשהם מגיעים מהשרת וכשחוזרים לשרת.

נניח שאתם יושבים בבית קפה ומשתמשים ברשת Wi-Fi ציבורית. אתם פותחים אתר של מסחר אלקטרוני וממלאים את פרטי כרטיס האשראי שלכם כדי לבצע רכישה. אם האתר משתמש ב-HTTP, כל מי (שבעל הכישורים לכך) מחובר לאותה רשת Wi-Fi ציבורית יכול לראות את פרטי כרטיס האשראי שלכם. אם באתר משתמשים ב-HTTPS, הנתונים מוצפנים ולכן מוגנים מפני כל ניסיון לגשת אליהם.

באתר שלכם, עליכם להקפיד גם להפנות את כל בקשות ה-HTTP ל-HTTPS. איך להפנות את כל התנועה אל HTTPS

איך לעזור למשתמשים לשמור על פרטיות הנתונים שלהם

במודול הראשון למדתם על שתי דרכים אפשריות להעברת נתונים: באמצעות בקשת GET ושימוש בבקשת POST.

עם בקשת GET, נתוני הטופס נכללים כמחרוזת שאילתה בכתובת ה-URL של הבקשה. אם שולחים טופס עם בקשת GET, הדפדפן יוסיף להיסטוריית הגלישה את כתובת ה-URL של הבקשה, כולל נתוני הטופס. האפשרות הזו נוחה אם רוצים לחפש טפסים שנשלחו בעבר, למשל טופס חיפוש. לא טוב בכלל, אם שולחים מידע אישי רגיש, וכל מי שיש לו גישה להיסטוריית הדפדפן או לרשת המקומית יכול לראות את המידע הזה.

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

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

מוודאים שהמשתמשים יכולים להירשם ולהיכנס לחשבון בצורה בטוחה

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

שיטות מומלצות לאימות חשבון ולניהול סיסמאות

איך לעזור למשתמשים לגשת למידע האישי שלהם

לאזורים רבים יש חוקים ותקנות בנושא הגנה על נתונים ופרטיות, כולל CCPA בקליפורניה ו-PDPA בהודו. כל אתר שזמין באיחוד האירופי (EU) צריך לעמוד בדרישות של General Data Protection Regulation (התקנה הכללית להגנה על מידע (GDPR)), גם אם האתר לא נמצא באיחוד האירופי.

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

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

צריך לוודא שהמשתמשים יכולים לעדכן את המידע האישי שלהם

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

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

דרישה לשלב אימות נוסף, כמו הזנה מחדש של הסיסמה הנוכחית, כדי להציג או לשנות מידע אישי באתר.

מידע נוסף: שיטות מומלצות לשמירה על פרטיות באפליקציות באינטרנט

מוודאים שכל הנתונים במצב טוב

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

האימות עוזר לוודא שפורמט הנתונים תקין, אבל עדיין לא כדאי לסמוך על נתונים שמשתמשים הזינו. איך אפשר להפיק את הנתונים בבטחה? כדי למנוע יצירת סקריפטים חוצי אתרים (XSS) ולהבטיח שכל הנתונים יהיו בטוחים להכללה ב-HTML, צריך לנקות את הנתונים לפני הפלט.

כדאי לקרוא מידע נוסף על חיטוי הנתונים לפני הפלט ולהשתמש ב-Sanitizer API כשאפשר.

חשוב לוודא שכל מה שנשלח אלינו הוא מאנשים אמיתיים

כדי להגן על הנתונים, יש מספר אפשרויות למניעת שליחה של ספאם מבוטים.

האפשרות הראשונה היא להשתמש בשירות כמו reCAPTCHA, על מנת להבחין בין אנשים אמיתיים לבין בוטים. לשם כך עליכם לכלול קטע JavaScript בדף ולהוסיף מאפיינים נוספים ללחצן Submit.

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

כד דבש

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

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

בחינת ההבנה

בוחנים את הידע שלכם בנושא אבטחה ופרטיות

מהי השיטה המועדפת להעברת מידע אישי באמצעות טפסים?

בקשה של GET.
בקשה של POST.
יונה של חברת תובלה.
HTTPS

איך אפשר למנוע ספאם?

שדה בטופס Honeypot.
שירותי ספאם.
מגישים רק מנות צמחוניות.
CAPTCHA

משאבים