אבטחה

עודכן ב־2026-09-22

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

בידוד בין חברות

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

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

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

סיסמאות

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

הרשאות לפי תפקיד

שלושה תפקידים, וההבדל ביניהם נאכף בשרת:

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

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

העברה ואחסון

כל התעבורה מוצפנת ב-HTTPS.
הנתונים מאוחסנים ב-Supabase באזור Frankfurt, Germany (European Union), עם הצפנה באחסון וגיבויים מנוהלים מצד הספק.
מפתח הניהול של בסיס הנתונים קיים רק בשרת, כמשתנה סביבה, ואינו מגיע לדפדפן בשום מצב. פעולות שדורשות אותו – למשל הזמנת משתמש חדש – רצות בצד השרת ומאמתות מי הקורא לפני שהן פועלות.
פרטי אמצעי תשלום אינם עוברים בשרתים שלנו ואינם נשמרים בהם.

מה איננו עושים

בתוך המערכת, אחרי ההתחברות, אין מעקב. בעמודי האתר הציבוריים נטענים כלי מדידה של צד שלישי (פיקסל של Meta ו-Google Analytics) רק אם אישרת בבאנר. פרטים במדיניות הפרטיות.
אין מעקב מיקום ואין ניטור עובדים. שעון הנוכחות כבוי כברירת מחדל, והעסק מחליט אם להפעיל אותו; מה שהוא רושם הוא שעת כניסה ושעת יציאה, בלי GPS ובלי מיקום המכשיר.
איננו מוכרים נתונים ואיננו משתפים אותם עם מפרסמים.

מה באחריותך

החלק הזה אינו קטן, ולכן הוא כתוב במפורש:

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

מצאת בעיה?

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

מה עוד לא קיים

כדי שהתמונה תהיה מלאה: אין עדיין אימות דו-שלבי, אין יומן פעולות (audit log) שנגיש ללקוח, ואין תקן SOC 2 או ISO 27001. אלה דברים שמתוכננים, ולא דברים שיש.

שאלה על אבטחה: support@setshifts.com

Security

Updated 2026-09-22

This page describes how the system protects your data, and the limits of that protection. A security page that promises everything is not a security page.

Isolation between companies

Each company sees only its own data. This does not rely on filtering in the screen; it is enforced by the database itself. Every table carries a permission rule that ties each row to a company, and it applies to every request – including one sent straight to the server rather than through the app. Code written in future that forgets a filter still cannot return another company's data.

Beyond that, sensitive columns have separate write permissions: subscription state, plan and valid-until date cannot be changed from the browser in any way – only the server writes them, in response to confirmation from the payment provider. The status of a support ticket and its reply are likewise written only on our side.

Isolation between companies is covered by automated tests that run on every code change, including deliberate attempts to read one company's data from another.

Passwords

Nobody here can see a password. Passwords are stored hashed in Supabase's authentication layer.
A manager never sees a member of staff's password either. There are two ways to bring someone in, and in neither does the password pass through the manager's screen: send an invitation – the person gets a link by email and chooses their own password; send sign-in details – the server draws a password, mails it straight to that person, and does not return it to the manager's browser. In the second case they should change it on first sign-in, through "Forgot password". Either way, a staff password should not be sent over WhatsApp and live there forever.
Invitation and reset links are single-use and expire. A link that has been used no longer works, and the token is stripped from the address immediately so it does not sit in browser history.
A six-character minimum is enforced on the server, not only in the screen.

Permissions by role

Three roles, and the difference between them is enforced on the server:

Role	What it can do
Owner	Everything, including the subscription and billing
Manager	Schedules, staff, locations, settings and users – no billing
Staff	By default: their own shifts and their own availability, without the full schedule or other people. A manager can turn on “Let staff see the whole team's schedule” in settings, and then staff also see who works each shift with them in the published schedule — names only. Where shift swaps are turned on, they also see the names of colleagues who can take their shift. Other people’s requests, notes, clock punches and contact details stay closed to them in every case, and they cannot edit the schedule

Staff update their own availability through defined server functions that check they are updating themselves, not by writing freely to a table. Even sending a handcrafted request straight to the server, they cannot change someone else's request, approve their own, or submit after the deadline the manager set.

In transit and at rest

All traffic is encrypted over HTTPS.
Data is stored in Supabase in the Frankfurt, Germany (European Union) region, with encryption at rest and provider-managed backups.
The database admin key exists only on the server, as an environment variable, and never reaches the browser. Operations that need it – inviting a new user, for instance – run server-side and verify who is calling before they act.
Payment details do not pass through our servers and are not stored there.

What we do not do

Inside the app, after sign-in, there is no tracking. On the public website pages, third-party measurement tools (Meta Pixel and Google Analytics) load only if you accept in the banner. Details in the privacy policy.
No location tracking and no staff monitoring. The time clock is off by default and the business decides whether to turn it on; what it records is a clock-in and a clock-out time, with no GPS and no device location.
We do not sell data and do not share it with advertisers.

What is on you

This part is not small, so it is spelled out:

Strong passwords, not ones reused from other services.
Deactivate a user who has left – while they are active, they can sign in.
Give the manager role only to people who should see the whole schedule and everyone on it.
Keep medical or personal details out of the free-text fields (a note on a staff card, a reason for a request) beyond what is needed.

Found a problem?

We want to hear about it, and we will not treat a report as an attack: support@setshifts.com. We acknowledge within 48 hours and keep you updated until it is closed. If a security incident affects customer data, we tell the affected customers directly, without waiting to be asked.

What does not exist yet

So the picture is complete: there is no two-factor authentication yet, no customer-visible audit log, and no SOC 2 or ISO 27001 certification. Those are planned, not present.

A security question: support@setshifts.com