Ασφάλεια στο Vibe Coding: Πώς να προστατεύσετε μια εφαρμογή που δημιουργήθηκε με AI

Περισσότερες οδηγίες για τη χρήση του Ailoot θα βρείτε στην τεκμηρίωση.

Γιατί παραβιάζονται συχνότερα οι εφαρμογές που δημιουργούνται με AI;#

Φτιάχνω κι εγώ προϊόντα με AI και δεν γίνομαι παρανοϊκός με την ασφάλεια σε σημείο να «κλειδώνω τα πάντα στο μέγιστο». Υπάρχει, όμως, ένα βασικό επίπεδο κάτω από το οποίο δεν πρέπει να πέσετε, αλλιώς μια μέρα θα ξυπνήσετε και θα βρείτε άδεια βάση δεδομένων και τους miners κάποιου άλλου στον διακομιστή σας. Αυτός ο οδηγός αφορά αυτό το βασικό επίπεδο. Όχι το «γίνετε ειδικός στην ασφάλεια», αλλά το «μην πυροβολείτε το πόδι σας χωρίς λόγο».

Η ρίζα του προβλήματος είναι απλή. Όταν λέτε σε έναν πράκτορα AI «φτιάξε μου μια εφαρμογή για να κλείνουν ραντεβού οι πελάτες», δημιουργεί την εφαρμογή όσο πιο γρήγορα γίνεται. Η ασφάλεια είναι επιπλέον δουλειά που δεν φαίνεται σε μια επίδειξη. Έτσι, η βάση δεδομένων ρυθμίζεται ώστε να είναι ανοιχτή, το κλειδί πληρωμών μπαίνει κατευθείαν στον κώδικα και ο έλεγχος για το «έχει πρόσβαση αυτός ο χρήστης;» υπάρχει μόνο στο πρόγραμμα περιήγησης, όπου μπορεί να παρακαμφθεί σε ένα δευτερόλεπτο.

Ο δεύτερος λόγος είναι οι ίδιες οι πλατφόρμες. Δείτε πώς περιγράφεται ο κίνδυνος:

Με άλλα λόγια, το κενό εμφανίζεται από μόνο του, από προεπιλογή. Δεν κάνατε κάτι λάθος. Απλώς δεν κάνατε τίποτα — και στην ασφάλεια, η αδράνεια σημαίνει ακριβώς «ανοιχτό σε όλους».

Υπάρχει και ένα τρίτο επίπεδο. Ένας πράκτορας μπορεί να δημοσιοποιήσει κλειδιά και κωδικούς πρόσβασης σε δημόσια αποθετήρια αν εκτελέσει git add . και git push χωρίς έλεγχο. Αν το αρχείο .env με τα κλειδιά σας δημοσιοποιηθεί μαζί με τον υπόλοιπο κώδικα, τα διαπιστευτήρια εκτίθενται.

Τι έχουν ήδη μάθει με τον δύσκολο τρόπο όσοι κάνουν vibe coding;#

Η καλύτερη προστασία από την απροσεξία είναι να μαθαίνουμε από τα λάθη των άλλων. Ακολουθούν τέσσερις αναφορές που αξίζει να δείτε πριν δημοσιεύσετε το έργο σας.

Lovable και απενεργοποιημένο RLS. Η πλατφόρμα Lovable δημιουργεί εφαρμογές από περιγραφές κειμένου. Το 2025 εντοπίστηκε ένα συστημικό κενό στις εφαρμογές της και του αποδόθηκε το CVE-2025-48757. Η αιτία: οι εφαρμογές που δημιουργήθηκαν δεν είχαν κανόνες πρόσβασης στη βάση δεδομένων σε επίπεδο γραμμής (RLS, το οποίο εξηγείται παρακάτω). Ένας ερευνητής εξέτασε ένα δείγμα και βρήκε 303 εκτεθειμένα σημεία πρόσβασης σε 170 εφαρμογές. Εκτέθηκαν ονόματα, αριθμοί τηλεφώνου, καταστάσεις πληρωμών, κλειδιά API άλλων ανθρώπων, ακόμη και διευθύνσεις κατοικίας. Σε περίπου 70 τοις εκατό των εφαρμογών που ελέγχθηκαν, η προστασία σε επίπεδο γραμμής ήταν εντελώς απενεργοποιημένη.

Tea και ευαίσθητα δεδομένα. Η εφαρμογή Tea (ανώνυμες κριτικές για ανθρώπους) έχασε περίπου 72,000 εικόνες τον Ιούλιο του 2025, μεταξύ των οποίων 13,000 selfies και φωτογραφίες εγγράφων, και στη συνέχεια πάνω από ένα εκατομμύριο ιδιωτικά μηνύματα. Η τεχνική αιτία ήταν ο ανοιχτός αποθηκευτικός χώρος και οι αδύναμοι έλεγχοι πρόσβασης. Η κοινότητα ασφάλειας αναφέρει το Tea ως χαρακτηριστικό παράδειγμα: όταν μια γρήγορη κυκλοφορία έχει μεγαλύτερη σημασία από τον έλεγχο των δικαιωμάτων, τα ευαίσθητα δεδομένα είναι τα πρώτα που διαρρέουν.

Ένα ακόμη πρακτικό παράδειγμα. Σε μια περίπτωση που περιέγραψε ο αρχικός συντάκτης, παραβιάστηκε η εφαρμογή ενός δημιουργού που έκανε vibe coding, επειδή το AI όρισε έναν προεπιλεγμένο κωδικό πρόσβασης κατά τη δημιουργία της βάσης δεδομένων — έναν κωδικό που μπορούσε να μαντευτεί αυτόματα. Έπειτα ακολούθησε η συνηθισμένη σειρά: εισέβαλαν, εγκατέστησαν miners και ξαναέγραψαν το έργο. Χρειάστηκε να διαγραφεί πλήρως ο διακομιστής. Ένας προεπιλεγμένος κωδικός πρόσβασης είναι μια ξεκλείδωτη πόρτα με επιγραφή «περάστε».

Δύο μέτωπα ασφάλειας: πού ακριβώς είστε ευάλωτοι;#

Όταν οι άνθρωποι μιλούν για «ασφάλεια στο vibe coding», συνήθως συγχέουν δύο εντελώς διαφορετικούς φόβους. Ας τους ξεχωρίσουμε, γιατί προστατεύεστε από αυτούς με διαφορετικούς τρόπους.

Πρώτο μέτωπο — ο ίδιος ο πράκτορας. Εκτελείτε έναν πράκτορα AI στον υπολογιστή σας και του δίνετε πρόσβαση στα αρχεία, στο τερματικό, στα κλειδιά και στη βάση δεδομένων. Ο κίνδυνος είναι ότι ένας πράκτορας δεν είναι άνθρωπος: ακολουθεί τις οδηγίες κατά γράμμα και θα βρει τη συντομότερη διαδρομή, ακόμη κι αν είναι επικίνδυνη. Σε αυτό περιλαμβάνεται και ο κίνδυνος να «εισαχθεί» εντολή κάποιου άλλου στον πράκτορα μέσω κειμένου που διαβάζει (αυτό λέγεται prompt injection).

Δεύτερο μέτωπο — η ολοκληρωμένη εφαρμογή. Αυτή είναι η εφαρμογή που δημοσιεύσατε και χρησιμοποιεί ο κόσμος. Στόχος είναι ο δημοσιευμένος ιστότοπος ή η υπηρεσία σας: οι εισβολείς αποκτούν πρόσβαση σε μια ανοιχτή βάση δεδομένων, στέλνουν πλαστά αιτήματα ή μαντεύουν λογαριασμούς άλλων ανθρώπων. Ο πράκτορας δεν έχει σχέση με αυτό — το κενό έμεινε ανοιχτό νωρίτερα και το εκμεταλλεύονται άλλοι.

Η Anthropic, η εταιρεία πίσω από το Claude, διατυπώνει έτσι την κύρια αρχή προστασίας — και ισχύει και για τα δύο μέτωπα:

Στην πράξη αυτό σημαίνει: μην υπολογίζετε ότι το AI θα «αποφύγει από μόνο του να κάνει κάτι κακό». Περιορίστε πρώτα όσα μπορεί να κάνει στην πράξη και μετά ζητήστε του να συμπεριφέρεται σωστά. Όταν αποτύχει η συμπεριφορά του — και θα αποτύχει — μόνο ένα σταθερό όριο που έχετε ορίσει εκ των προτέρων θα σας προστατεύσει.

Θέλετε το AI να λειτουργεί προβλέψιμα και να σταματήσει να πυροβολεί το πόδι σας σε κάθε νέο έργο; Οι κανόνες ασφάλειας αποτελούν μέρος του Second Brain σας: καταγράψτε τους μία φορά στο CLAUDE.md και ο πράκτορας θα τους ακολουθεί σε κάθε αίτημα.

Τι μπορεί να κάνει ένας πράκτορας AI με πρόσβαση στον υπολογιστή σας;#

Ο κίνδυνος που υποτιμάται περισσότερο είναι ο δικός σας πράκτορας με υπερβολικά ευρεία δικαιώματα. Δεν χρειάζεστε καν εξωτερικό χάκερ.

Δεν υπήρχε κακόβουλη πρόθεση. Απλώς ένας πράκτορας στον οποίο έχει ανατεθεί να «λύσει την εργασία» βρίσκει μια δομική αδυναμία ταχύτερα από έναν άνθρωπο. Και αν αυτή η αδυναμία του δίνει πρόσβαση στα κλειδιά ή στο περιβάλλον παραγωγής σας, θα τη χρησιμοποιήσει. Άρα ο πρώτος κανόνας είναι τα ελάχιστα δικαιώματα. Δώστε σε έναν πράκτορα ακριβώς τόση πρόσβαση όση χρειάζεται για μια συγκεκριμένη εργασία — ούτε σταγόνα παραπάνω.

Τι μπορείτε να κάνετε στην πράξη, ακόμη κι αν δεν είστε προγραμματιστής;

1. Μην εκτελείτε τον πράκτορα σε λειτουργία «επιτρέπονται όλα» σε μηχάνημα παραγωγής

   Μια λειτουργία όπου ο πράκτορας δεν ζητά επιβεβαίωση (συχνά ονομάζεται bypass ή yolo) προορίζεται μόνο για sandbox ή δοκιμαστικό έργο, όχι για μηχάνημα που περιέχει λειτουργικά κλειδιά και πρόσβαση στο περιβάλλον παραγωγής.

2. Απαγορεύστε στον πράκτορα να διαβάζει μυστικά

   Στο Claude Code, το κάνετε με έναν κανόνα που αρνείται την πρόσβαση σε αρχεία που περιέχουν κλειδιά. Έτσι, ακόμη κι αν ο πράκτορας θέλει να ανοίξει το .env, το εργαλείο δεν θα τον αφήσει.

3. Κρατήστε χωριστά τα κλειδιά παραγωγής

   Τα κλειδιά για τη βάση δεδομένων παραγωγής και την υπηρεσία πληρωμών δεν πρέπει να βρίσκονται στον ίδιο φάκελο όπου ο πράκτορας γράφει κώδικα. Διατηρήστε χωριστά τα περιβάλλοντα: χρησιμοποιείτε δοκιμαστικά κλειδιά όταν πειραματίζεστε.

4. Χρησιμοποιήστε το sandbox του εργαλείου

   Τα σύγχρονα εργαλεία AI μπορούν να εκτελούν εντολές απομονωμένα (σε sandbox), χωρίς πρόσβαση στο υπόλοιπο σύστημα. Στο Claude Code, αυτό μειώνει τα αιτήματα δικαιωμάτων κατά περίπου 84 τοις εκατό — άρα είναι και πιο βολικό.

Ένας κανόνας στο Claude Code που αρνείται την ανάγνωση μυστικών μοιάζει περίπου έτσι — προσθέστε τον στις ρυθμίσεις δικαιωμάτων:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

Πού δεν πρέπει ποτέ να βάζετε κλειδιά API και κωδικούς πρόσβασης;#

Το φθηνότερο και συχνότερο λάθος είναι να βάζετε κλειδιά μέσα στον κώδικα. Ένα κλειδί API για υπηρεσία πληρωμών, ένας κωδικός πρόσβασης βάσης δεδομένων, ένα διακριτικό bot — όλα αυτά είναι μυστικά. Ανήκουν σε ξεχωριστό αρχείο .env και αυτό το αρχείο πρέπει να αναφέρεται στο .gitignore, ώστε να μην προστεθεί στο git μαζί με τον κώδικα.

Η συνηθισμένη σειρά είναι η εξής: bot εντοπίζουν ένα κλειδί cloud, ξεκινούν διακομιστές εξόρυξης κρυπτονομισμάτων με δικά σας έξοδα και μέχρι το πρωί βρίσκεστε αντιμέτωποι με υπέρογκο λογαριασμό. Οι προγραμματιστές αφηγούνται τακτικά τέτοιες ιστορίες και οι λογαριασμοί φτάνουν σε πενταψήφια ποσά σε δολάρια.

Η κλίμακα του προβλήματος το 2025: 28.65 εκατομμύρια νέα μυστικά ενσωματωμένα σε κώδικα σε δημόσια αποθετήρια, αύξηση 34 τοις εκατό σε ετήσια βάση. Οι διαρροές κλειδιών ειδικά για υπηρεσίες AI αυξήθηκαν κατά 81 τοις εκατό. Το vibe coding ρίχνει κι άλλο λάδι στη φωτιά, επειδή ο πράκτορας κάνει commit χωρίς να κοιτάξει.

Τι να ελέγξετε χειροκίνητα τώρα:

1. Ανοίξτε το αρχείο .gitignore του έργου

   Βεβαιωθείτε ότι περιέχει μια γραμμή .env. Αν δεν υπάρχει, προσθέστε την πριν από το πρώτο commit.

2. Μεταβείτε στο αποθετήριό σας στο GitHub

   Ελέγξτε ότι δεν υπάρχει εκεί το αρχείο .env. Μια γρήγορη μέθοδος ελέγχου είναι να αναζητήσετε στο αποθετήριο το .env ή ένα μέρος του κλειδιού σας.

3. Αν διέρρευσε ένα κλειδί, ανακαλέστε το και εκδώστε νέο

   Δεν αρκεί να διαγράψετε το commit: το κλειδί μπορεί να έχει ήδη κλαπεί. Μεταβείτε στην υπηρεσία (πάροχο πληρωμών, υπηρεσία cloud, πάροχο AI), ανακαλέστε το παλιό κλειδί και εκδώστε νέο. Αυτό λέγεται περιστροφή κλειδιού.

4. Δώστε στα κλειδιά τα ελάχιστα δικαιώματα

   Αν ένα κλειδί χρειάζεται μόνο για ανάγνωση, κάντε το μόνο για ανάγνωση. Έτσι, ακόμη κι αν διαρρεύσει, θα μπορούν να κλέψουν λιγότερα.

Γιατί μπορούν όλοι να δουν τη βάση δεδομένων σας χωρίς RLS;#

Αν δημιουργείτε μια εφαρμογή στο Supabase ή σε παρόμοια βάση δεδομένων, αυτή είναι η σημαντικότερη ενότητα. Το RLS σημαίνει Row Level Security. Με απλά λόγια, είναι ένας κανόνας που καθορίζει ποιες γραμμές ενός πίνακα εμφανίζονται σε έναν συγκεκριμένο χρήστη. Χωρίς αυτόν, ο πίνακας «orders» επιστρέφει σε όλους τις παραγγελίες κάθε πελάτη.

Δείτε πώς το διατυπώνει απλά η ίδια η τεκμηρίωση του Supabase:

Και εδώ βρίσκεται η βασική παγίδα για όποιον κάνει vibe coding. Όταν δημιουργείτε έναν πίνακα κάνοντας κλικ στον πίνακα ελέγχου του Supabase, η προστασία ενεργοποιείται αυτόματα. Όταν όμως τον δημιουργεί το AI — και σχεδόν πάντα γράφει απευθείας εντολές SQL — το RLS παραμένει απενεργοποιημένο από προεπιλογή. Αυτό σημαίνει ότι ένας πίνακας που δημιούργησε πράκτορας είναι σχεδόν βέβαιο ότι είναι ανοιχτός σε όλο το διαδίκτυο. Έτσι ακριβώς διέρρευσαν δεδομένα από εκείνες τις 170 εφαρμογές Lovable.

Τι να κάνετε:

1. Ρωτήστε απευθείας τον πράκτορα

   Γράψτε: «δείξε μου όλους τους πίνακες στους οποίους είναι απενεργοποιημένο το RLS». Το AI θα δημιουργήσει μια λίστα — αυτή είναι η λίστα εργασιών σας.

2. Ενεργοποιήστε το RLS σε κάθε πίνακα με δεδομένα χρηστών

   Και προσθέστε τουλάχιστον μία πολιτική πρόσβασης — για παράδειγμα, «ένας χρήστης μπορεί να βλέπει μόνο τις δικές του γραμμές».

3. Ελέγξτε τον πίνακα ελέγχου

   Στον πίνακα ελέγχου του Supabase, κάθε πίνακας πρέπει να εμφανίζει «RLS enabled». Αν είναι γκρι ή κόκκινος, σημαίνει ότι ο πίνακας είναι ανοιχτός.

4. Δοκιμάστε το στην πράξη

   Συνδεθείτε ως απλός χρήστης και προσπαθήστε να ζητήσετε τα δεδομένα κάποιου άλλου. Αν η πρόσβαση απορριφθεί, η πολιτική λειτουργεί.

Γιατί δεν σας προστατεύουν οι έλεγχοι δικαιωμάτων στη διεπαφή;#

Μια συνηθισμένη πλάνη είναι: «φρόντισα ώστε οι απλοί χρήστες να μην μπορούν να δουν το κουμπί διαχειριστή». Το πρόβλημα είναι ότι ένα κουμπί είναι απλώς μια εικόνα στο πρόγραμμα περιήγησης. Ένα αίτημα μπορεί να σταλεί κατευθείαν στον διακομιστή χωρίς να χρησιμοποιηθεί το κουμπί. Αν ο διακομιστής δεν ελέγξει ξανά τα δικαιώματα, θα εκτελέσει την εντολή κάποιου άλλου.

Ένα κλασικό παράδειγμα λέγεται IDOR. Φανταστείτε ότι ανοίγετε την παραγγελία σας σε μια διεύθυνση με id=123. Αλλάξτε το σε id=124 και μπορείτε να δείτε την παραγγελία κάποιου άλλου, επειδή ο διακομιστής δεν έλεγξε αν ήταν πράγματι δική σας. Αυτό είναι ένα από τα συνηθέστερα κενά στις εφαρμογές που δημιουργούνται με vibe coding, και οι αδύναμοι έλεγχοι δικαιωμάτων συνέβαλαν στη διαρροή του Tea.

Ο κανόνας είναι απλός: επαναλάβετε στον διακομιστή κάθε έλεγχο του τύπου «επιτρέπεται σε αυτόν τον χρήστη να το κάνει;». Η διεπαφή εξυπηρετεί την ευκολία· η προστασία ανήκει στο backend. Μια έτοιμη οδηγία για τον πράκτορα: «πρόσθεσε ελέγχους δικαιωμάτων στην πλευρά του διακομιστή για κάθε endpoint που διαβάζει ή αλλάζει δεδομένα χρηστών· μην βασίζεσαι στο ότι ένα στοιχείο είναι κρυφό στη διεπαφή».

Πώς μπορείτε να ελέγξετε τον κώδικα για κενά αν δεν είστε προγραμματιστής;#

Τα καλά νέα: σήμερα μπορείτε να ζητήσετε από το ίδιο AI να ελέγξει την ασφάλεια — κάνει αξιοπρεπή δουλειά εντοπίζοντας συνηθισμένα κενά. Ακολουθούν τρία εργαλεία για διαφορετικές εργασίες.

1. Η εντολή /security-review στο Claude Code. Ένας εφάπαξ έλεγχος του τρέχοντος branch για SQL injection, XSS, κενά εξουσιοδότησης, διαρροές δεδομένων και προβλήματα εξαρτήσεων. Εξήγησα βήμα προς βήμα πώς λειτουργεί και πώς να προσθέσετε έναν αυτόματο έλεγχο σε κάθε αλλαγή σε ξεχωριστό οδηγό για τον έλεγχο ασφάλειας στο Claude Code. Το βασικό σημείο εδώ: είναι η πρώτη γραμμή άμυνας, που ξεκινά με μία εντολή.

2. Το επίσημο πρόσθετο security-guidance. Εγκαταστήστε το από την επίσημη αγορά πρόσθετων με /plugin install security-guidance@claude-plugins-official (απαιτείται Claude Code έκδοσης 2.1.144 ή νεότερης). Ελέγχει τον κώδικα σε τρία σημεία: σε κάθε επεξεργασία, στο τέλος κάθε turn και κατά το commit. Εντοπίζει παρακάμψεις εξουσιοδότησης, IDOR, injections και αδύναμη κρυπτογραφία. Η Anthropic, ωστόσο, δηλώνει ανοιχτά τους περιορισμούς του:

npx skills add <author>/<repo>

Έπειτα, απλώς πείτε στον πράκτορα: «έλεγξε το έργο μου για ευπάθειες». Υπάρχει, όμως, μια σημαντική επιφύλαξη σχετικά με αυτή τη συλλογή, γι’ αυτό και της αφιέρωσα ξεχωριστή ενότητα παρακάτω.

Για να έχετε μια εικόνα: σημαντικοί παράγοντες έχουν επίσης αρχίσει να αντιμετωπίζουν σοβαρά την ασφάλεια του κώδικα AI. Στο πλαίσιο του Project Glasswing, το οποίο επεκτάθηκε στις 2 Ιουνίου 2026 ώστε να περιλαμβάνει 150 οργανισμούς, οι συνεργάτες εντόπισαν περισσότερες από 10,000 κρίσιμες ευπάθειες σε σύντομο χρονικό διάστημα χρησιμοποιώντας μοντέλα Anthropic. Το διακύβευμα είναι σαφές:

Μπορείτε να εμπιστευτείτε δεξιότητες και επεκτάσεις από το GitHub;#

Εδώ τα πράγματα γίνονται ιδιαίτερα περίπλοκα, επειδή ο κίνδυνος προέρχεται από ένα εργαλείο που εγκαθιστάτε για λόγους ασφάλειας. Όταν εκτελείτε npx skills add ... ή εγκαθιστάτε μια επέκταση, εισάγετε κώδικα κάποιου άλλου, τον οποίο στη συνέχεια εκτελεί ο πράκτορας με τα δικά σας δικαιώματα. Αν ο δημιουργός του έχει δεχτεί επίθεση ή το πακέτο ήταν εξαρχής κακόβουλο, έχετε πρόβλημα.

Πάρτε τη συλλογή δεξιοτήτων από την προηγούμενη ενότητα. Το όνομά της περιλαμβάνει τη λέξη «Anthropic», πράγμα που σας κάνει να χαλαρώνετε την προσοχή σας. Όμως η ίδια η περιγραφή της λέει ξεκάθαρα:

Με άλλα λόγια, το όνομα είναι παραπλανητικό. Η ίδια η συλλογή είναι αυτή τη στιγμή ώριμη και καθαρή, αλλά η αρχή παραμένει: την εγκαθιστάτε με δική σας ευθύνη. Και η απειλή δεν είναι θεωρητική. Τον Μάιο του 2026, μια κακόβουλη επέκταση επεξεργαστή έμεινε στην αγορά μόλις 18 λεπτά — και σε αυτό το διάστημα κατάφερε να κλέψει κωδικούς πρόσβασης από password managers, διακριτικά GitHub, πρόσβαση σε υπηρεσίες cloud, ακόμη και διαμορφώσεις Claude Code από όσους την εγκατέστησαν. Μια ακόμη δυσάρεστη λεπτομέρεια: τέτοιο κακόβουλο λογισμικό συχνά επιβιώνει από τη συνήθη αφαίρεση του πακέτου και εκτελείται ξανά στην επόμενη συνεδρία.

Έχω υιοθετήσει μια απλή συνήθεια και τη συνιστώ και σε εσάς: πριν εγκαταστήσετε οποιαδήποτε δεξιότητα από το GitHub, ελέγξτε την μόνοι σας. Οι δημιουργοί μπορεί να δεχτούν επίθεση, οι λογαριασμοί να καταληφθούν και κακόβουλο λογισμικό να βρεθεί σε ένα αποθετήριο. Ο έλεγχος είναι η δικλίδα ασφαλείας σας.

Το πρακτικό ελάχιστο πριν από την εγκατάσταση: εξετάστε τον δημιουργό και τον αριθμό αστεριών, διαβάστε την περιγραφή της δεξιότητας, μην εγκαθιστάτε ένα εργαλείο «επειδή προτάθηκε σε μια ανάρτηση» και, για ένα άγνωστο εργαλείο, δοκιμάστε το πρώτα σε ξεχωριστό δοκιμαστικό περιβάλλον και όχι σε μηχάνημα με κλειδιά παραγωγής.

Τι θα σας σώσει μετά από μια παραβίαση: αντίγραφα ασφαλείας και επαναφορά#

Η ασφάλεια δεν αφορά μόνο το «να κρατάμε τους ξένους έξω», αλλά και το «να επανερχόμαστε στην κανονικότητα όταν κάτι πάει στραβά». Γιατί κάτι θα πάει στραβά. Στην πρακτική περίπτωση που περιγράφεται, ένας πράκτορας AI διέγραψε μια ενεργή βάση δεδομένων σε έργο παραγωγής, ενώ εκτελούσε μια συνηθισμένη εργασία. Υπήρχε αντίγραφο ασφαλείας, αλλά ήταν τριών ημερών — και χάθηκαν απλώς δεδομένα τριών ημερών.

Αυτό οδηγεί σε δύο κανόνες.

Δημιουργείτε αντίγραφα ασφαλείας συχνά. Αν η εφαρμογή σας περιέχει δεδομένα που δεν θα θέλατε να χάσετε, ένα αντίγραφο κάθε τρεις ημέρες αποτελεί ψευδαίσθηση προστασίας. Ρυθμίστε αυτόματα αντίγραφα ασφαλείας τουλάχιστον κάθε 30 λεπτά. Για τις περισσότερες βάσεις δεδομένων, συμπεριλαμβανομένου του Supabase, αυτό μπορεί να ενεργοποιηθεί με λίγα κλικ.

Το Git είναι ασφάλεια απέναντι στον πράκτορα. Το Git αποθηκεύει το ιστορικό του κώδικά σας: μπορείτε να επαναφέρετε οποιαδήποτε λειτουργική κατάσταση. Όταν ένας πράκτορας ξαναγράφει κάτι που λειτουργούσε, επιστρέφετε στην τελευταία λειτουργική έκδοση αντί να το διορθώνετε χειροκίνητα. Αν το AI διέγραψε ή χάλασε το έργο και δεν ξέρετε πώς να το επαναφέρετε, δείτε τη ξεχωριστή αναφορά: τι να κάνετε αν το AI διέγραψε τη βάση δεδομένων. Για να προστατευτείτε εκ των προτέρων από ζημιές στο έργο, δείτε τον οδηγό πώς να προστατεύσετε το Claude Code από ζημιές.

Λίστα ελέγχου ασφάλειας πριν από τη δημοσίευση#

Περάστε αυτή τη λίστα ακριβώς πριν από τη δημοσίευση. Με τη σειρά.

1. Μυστικά στο .env και το .env στο .gitignore. Κανένα κλειδί μέσα στον κώδικα. Κανένα αρχείο .env σε δημόσιο αποθετήριο.

2. Κλειδιά με ελάχιστα δικαιώματα. Κάθε κλειδί μπορεί να κάνει μόνο όσα χρειάζονται. Τα κλειδιά παραγωγής είναι χωριστά από το περιβάλλον του πράκτορα.

3. Το RLS είναι ενεργοποιημένο σε όλους τους πίνακες με δεδομένα χρηστών και υπάρχουν πολιτικές πρόσβασης.

4. Έλεγχοι δικαιωμάτων στην πλευρά του διακομιστή για κάθε ενέργεια στα δεδομένα. Δεν αρκεί να κρύψετε ένα κουμπί στη διεπαφή. Έχετε δοκιμάσει χειροκίνητα να αλλάξετε το id στη διεύθυνση.

5. Επαλήθευση υπογραφής webhook. Κάθε χειριστής εξωτερικών ειδοποιήσεων (πληρωμές, φόρμες) επαληθεύει την υπογραφή.

6. Περιορισμός ρυθμού στα εισερχόμενα αιτήματα και στις δαπανηρές λειτουργίες, ώστε να μην μπορούν να μαντευτούν κωδικοί πρόσβασης με επιθέσεις ωμής βίας και να μην εκτοξευτεί ο λογαριασμός σας.

7. Ο πράκτορας δεν εκτελείται σε λειτουργία «επιτρέπονται όλα» σε μηχάνημα με κλειδιά παραγωγής. Η ανάγνωση του .env απαγορεύεται.

8. Τα αντίγραφα ασφαλείας είναι συχνά και δοκιμασμένα — έχετε πράγματι δοκιμάσει να κάνετε επαναφορά, αντί απλώς να πιστεύετε ότι τα αντίγραφα «κάπου υπάρχουν».

9. Ο κώδικας έχει ελεγχθεί με το /security-review ή το πρόσθετο security-guidance. Τα ευρήματα έχουν διορθωθεί.

10. Οι δεξιότητες και οι επεκτάσεις άλλων ανθρώπων έχουν ελεγχθεί πριν από την εγκατάσταση. Τίποτα δεν εγκαταστάθηκε «στα τυφλά».

Από πού να ξεκινήσετε σήμερα#

Μην προσπαθήσετε να εφαρμόσετε όλα όσα περιέχει αυτός ο οδηγός μέσα σε ένα βράδυ — στο τέλος δεν θα κάνετε τίποτα. Κάντε τα τρία σημαντικότερα βήματα για σήμερα:

1. Ελέγξτε τα μυστικά σας. Ανοίξτε το .gitignore, βεβαιωθείτε ότι αναφέρεται το .env και ελέγξτε ότι δεν υπάρχουν κλειδιά στο δημόσιο αποθετήριο. Αν έχουν διαρρεύσει, ανακαλέστε τα και εκδώστε νέα.
2. Ρωτήστε για το RLS. Πείτε στον πράκτορα: «δείξε μου τους πίνακες στους οποίους είναι απενεργοποιημένο το RLS» — και ενεργοποιήστε το παντού όπου αποθηκεύονται δεδομένα ανθρώπων.
3. Ρυθμίστε συχνά αντίγραφα ασφαλείας. Έτσι, αν κάτι πάει στραβά, θα χάσετε λεπτά αντί για ημέρες.

Έπειτα, ακολουθήστε την παραπάνω λίστα ελέγχου καθώς μεγαλώνει το έργο σας και αρχίζει να διαχειρίζεται χρήματα και δεδομένα άλλων ανθρώπων.

Ένα τελευταίο σημείο. Η ασφάλεια στο vibe coding αφορά την ευθύνη του ιδιοκτήτη. Δεν χρειάζεται να γίνετε ειδικός στην ασφάλεια. Το AI δημιούργησε το προϊόν σας μέσα σε ένα βράδυ — ωραία, αλλά εσείς είστε υπεύθυνοι γι’ αυτό. Στην πράξη, αυτό σημαίνει το βασικό επίπεδο που περιγράφεται σε αυτόν τον οδηγό.

Θέλετε το AI να λειτουργεί προβλέψιμα και να σταματήσει να πυροβολεί το πόδι σας σε κάθε νέο έργο; Οι κανόνες ασφάλειας πρέπει να καταγράφονται στο CLAUDE.md, ώστε ο πράκτορας να τους ακολουθεί σε κάθε αίτημα.

Για περαιτέρω εργασία με μοντέλα, μπορείτε να μεταβείτε στο Ailoot.