Έλεγχος εγκυρότητας δεδομένων εισόδου σε εφαρμογές για κινητά — βασικές αρχές, μέθοδοι ελέγχου και υλοποίηση

Τι είναι ο έλεγχος εγκυρότητας δεδομένων εισόδου;

Ο έλεγχος εγκυρότητας δεδομένων εισόδου είναι ο έλεγχος ότι τα δεδομένα που εισέρχονται στην εφαρμογή από τον χρήστη, μια εξωτερική υπηρεσία ή κάποιο άλλο στοιχείο ανταποκρίνονται στα αναμενόμενα κριτήρια. Τα κριτήρια αυτά περιλαμβάνουν τον τύπο δεδομένων (συμβολοσειρά, αριθμός, ημερομηνία), τη μορφή (email, URL, τηλέφωνο), το εύρος τιμών (ηλικία από 18 έως 120), το μήκος (κωδικός πρόσβασης από 8 έως 128 χαρακτήρες) και τους επιτρεπόμενους χαρακτήρες (μόνο λατινικοί χαρακτήρες, ψηφία, παύλα). Χωρίς έλεγχο, η εφαρμογή μπορεί να επεξεργαστεί δεδομένα που θα προκαλέσουν σφάλματα εκτέλεσης, καταστροφή δεδομένων ή ευπάθειες ασφαλείας.

Γιατί ο έλεγχος είναι κρίσιμο στοιχείο ασφαλείας;

Η έλλειψη ελέγχου εγκυρότητας των δεδομένων εισόδου είναι η βασική αιτία ευπαθειών όπως SQL Injection, XSS, Command Injection, Path Traversal και Buffer Overflow. Σύμφωνα με το MITRE CWE (2025), το CWE-20 (Improper Input Validation) καταλαμβάνει τη δεύτερη θέση στην κατάταξη των πιο επικίνδυνων σφαλμάτων λογισμικού. Ο έλεγχος είναι η πρώτη γραμμή άμυνας στο μοντέλο ασφαλείας Defense in Depth: αποκόπτει τα λανθασμένα δεδομένα πριν φτάσουν σε άλλα στοιχεία του συστήματος.

Έλεγχος vs Καθαρισμός

Ο έλεγχος απορρίπτει τα δεδομένα που δεν πληρούν τα κριτήρια. Ο καθαρισμός τροποποιεί τα δεδομένα αφαιρώντας ή κωδικοποιώντας τα επικίνδυνα μέρη. Για παράδειγμα, κατά την εισαγωγή περιεχομένου HTML, ο έλεγχος μπορεί να ελέγξει το μήκος του κειμένου, ενώ ο καθαρισμός μπορεί να αφαιρέσει τα script tags μέσω της βιβλιοθήκης HTML Purifier ή του DOMPurify. Ο καθαρισμός δεν αντικαθιστά τον έλεγχο: λειτουργούν μαζί. Ο έλεγχος είναι πολιτική "επιτρέπεται/απαγορεύεται", ο καθαρισμός είναι "καθαρίστηκε πριν τη χρήση".

Τύποι ελέγχου εγκυρότητας δεδομένων εισόδου

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

Έλεγχος μορφής

Έλεγχος τύπου δεδομένων, μεγέθους, μορφής και επιτρεπόμενων χαρακτήρων. Υλοποιείται μέσω κανονικών εκφράσεων, ενσωματωμένων τύπων γλωσσών και βιβλιοθηκών ελέγχου. Παραδείγματα: έλεγχος UUID (μορφή 8-4-4-4-12 δεκαεξαδικά ψηφία), έλεγχος τηλεφωνικού αριθμού (μόνο ψηφία, + στην αρχή, από 7 έως 15 χαρακτήρες), έλεγχος ακέραιου αριθμού (τιμή στο εύρος Integer.MIN_VALUE — Integer.MAX_VALUE). Ο έλεγχος μορφής είναι το ελάχιστο απαραίτητο επίπεδο για κάθε πεδίο εισόδου.

Σημασιολογικός έλεγχος

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

Επιχειρηματικός έλεγχος

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

Έλεγχος στην πλευρά του πελάτη και του διακομιστή

Ο έλεγχος στην πλευρά του πελάτη (στο πρόγραμμα περιήγησης ή στην εφαρμογή για κινητά) χρειάζεται για την ευκολία του χρήστη: άμεση ανατροφοδότηση χωρίς αποστολή δεδομένων στον διακομιστή. Ωστόσο, ο έλεγχος στον διακομιστή είναι ο μόνος αξιόπιστος, καθώς ο κώδικας του πελάτη μπορεί πάντα να παρακαμφθεί. Στείλτε αιτήματα μέσω εργαλείων προγραμματιστή, του Postman ή ενός διακομιστή μεσολάβησης (Burp Suite) — και ο έλεγχος στην πλευρά του πελάτη παύει να υφίσταται. Σύμφωνα με το PortSwigger Research (2025), πάνω από το 90% των δοκιμασμένων διαδικτυακών εφαρμογών βασίζονται αποκλειστικά στον έλεγχο στην πλευρά του πελάτη για τουλάχιστον ένα πεδίο.

Κανόνας: πελάτης — για UX, διακομιστής — για ασφάλεια

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

Υλοποίηση ελέγχου στην πλευρά του πελάτη

Στο διαδίκτυο — χαρακτηριστικά HTML5 (required, pattern, min/max, type="email") και JavaScript. Στις εφαρμογές για κινητά — εγγενείς επαληθευτές πεδίων κειμένου (InputFilter στο Android, textField(:shouldChangeCharactersIn:) στο iOS). React Hook Form και Formik για React, Vuelidate για Vue, Angular Reactive Forms — δημοφιλείς βιβλιοθήκες για έλεγχο στην πλευρά του πελάτη. Όλες υποστηρίζουν προσαρμοσμένους κανόνες και ασύγχρονο έλεγχο (έλεγχο μοναδικότητας του ονόματος χρήστη στον διακομιστή).

// Παράδειγμα ελέγχου στον διακομιστή σε Express με Joi
const Joi = require('joi');

const userSchema = Joi.object({
    email: Joi.string()
        .email()
        .required()
        .max(255),
    age: Joi.number()
        .integer()
        .min(18)
        .max(120)
        .required(),
    password: Joi.string()
        .pattern(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,128}$/)
        .required()
});

app.post('/api/users', async (req, res) => {
    const { error, value } = userSchema.validate(req.body);
    if (error) {
        return res.status(400).json({
            error: error.details[0].message
        });
    }
    // value — ήδη ελεγμένα και ασφαλή δεδομένα
    const user = await User.create(value);
    res.status(201).json(user);
});

Έλεγχος σε εφαρμογές για κινητά

Οι εφαρμογές για κινητά θέτουν ιδιαίτερες απαιτήσεις στον έλεγχο δεδομένων. Η οθόνη είναι μικρότερη — τα σφάλματα πρέπει να είναι συνοπτικά, το πληκτρολόγιο συμφραζόμενο (αριθμητικό για την εισαγωγή αριθμών), και ο έλεγχος ασύγχρονος για να μην μπλοκάρει τη διεπαφή. Οι εγγενείς πλατφόρμες παρέχουν ενσωματωμένους μηχανισμούς ελέγχου που πρέπει να χρησιμοποιούνται από προεπιλογή. Το Material Design Guidelines για Android και το Human Interface Guidelines για iOS περιέχουν λεπτομερείς συστάσεις για την εμφάνιση σφαλμάτων ελέγχου.

Έλεγχος στο Android (Jetpack Compose)

Το Jetpack Compose προσφέρει μια δηλωτική προσέγγιση στον έλεγχο μέσω διαχείρισης κατάστασης. Κάθε πεδίο εισόδου συνδέεται με μια κατάσταση (MutableState) και το σφάλμα υπολογίζεται βάσει της τρέχουσας τιμής. Η βιβλιοθήκη Compose Validator απλοποιεί τη δημιουργία κανόνων: required, email, min/max length, pattern. Ο έλεγχος ενεργοποιείται κατά την αλλαγή του κειμένου (onValueChange) ή κατά την προσπάθεια υποβολής της φόρμας. Συνιστάται η εμφάνιση του σφάλματος μόνο μετά την πρώτη υποβολή ή αφού ο χρήστης ολοκληρώσει την εισαγωγή (debounce 300-500ms).

Έλεγχος στο iOS (SwiftUI)

Το SwiftUI δεν διαθέτει ενσωματωμένο μηχανισμό ελέγχου φορμών, αλλά επιτρέπει την εύκολη υλοποίησή του μέσω Combine και property wrappers. Χρησιμοποιήστε @State για την τιμή του πεδίου και μια υπολογιζόμενη ιδιότητα για το σφάλμα. Το πλαίσιο ValidatedPropertyKit παρέχει έτοιμους διακοσμητές: @Validated().email(), @Validated().range(18...120). Σύσταση iOS — χρησιμοποιήστε τους τύπους πληκτρολογίου (UIKeyboardType.emailAddress, .numberPad) και την αυτόματη κεφαλαιοποίηση για να μειώσετε τον αριθμό σφαλμάτων στο επίπεδο εισαγωγής.

Έλεγχος στο Flutter

Το Flutter παρέχει την κλάση Form και TextFormField με ενσωματωμένο έλεγχο μέσω του callback validator. Κάθε πεδίο επιστρέφει σφάλμα ως συμβολοσειρά ή null αν τα δεδομένα είναι σωστά. Το FormState.validate() ενεργοποιεί τον έλεγχο όλων των πεδίων της φόρμας. Το πακέτο reactive_forms για πολύπλοκες περιπτώσεις: προσαρμοσμένοι επαληθευτές, ασύγχρονος έλεγχος, δυναμικοί κανόνες. Το Flutter Web και η έκδοση για κινητά χρησιμοποιούν το ίδιο API, γεγονός που απλοποιεί τη συντήρηση.

// Παράδειγμα ελέγχου φόρμας στο Flutter
Form(
    key: _formKey,
    child: Column(
        children: [
            TextFormField(
                decoration: InputDecoration(labelText: 'Email'),
                validator: (value) {
                    if (value == null || value.isEmpty) {
                        return 'Email is required';
                    }
                    if (!RegExp(r'^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$')
                            .hasMatch(value)) {
                        return 'Enter a valid email';
                    }
                    return null;
                },
            ),
            ElevatedButton(
                onPressed: () {
                    if (_formKey.currentState!.validate()) {
                        // Process valid data
                    }
                },
                child: Text('Submit'),
            ),
        ],
    ),
)

Τεχνικές και εργαλεία ελέγχου

Τα σύγχρονα πλαίσια παρέχουν ενσωματωμένους επαληθευτές που καλύπτουν το 80% των αναγκών. Το υπόλοιπο 20% απαιτεί προσαρμοσμένους κανόνες, κανονικές εκφράσεις ή σύνθεση υπαρχόντων. Η βασική αρχή — ο έλεγχος πρέπει να είναι δηλωτικός ώστε να μπορεί να διαβάζεται, να δοκιμάζεται και να συντηρείται εύκολα. Αποφύγετε τη λογική ελέγχου διασκορπισμένη σε ελεγκτές και οθόνες — μεταφέρετέ την σε ξεχωριστές κλάσεις ή σχήματα.

Προσεγγίσεις White-list vs Black-list

White-list (λευκή λίστα) — καθορίζετε ποια δεδομένα επιτρέπονται, όλα τα υπόλοιπα απορρίπτονται. Black-list — καθορίζετε ποια δεδομένα απαγορεύονται, όλα τα υπόλοιπα επιτρέπονται. Η white-list είναι πάντα πιο αξιόπιστη: γνωρίζετε ακριβώς ποια δεδομένα θα περάσουν. Η black-list απαιτεί την πρόβλεψη όλων των πιθανών επιθέσεων, κάτι που είναι αδύνατο. Παράδειγμα: κατά τον έλεγχο της ηλικίας χρησιμοποιήστε white-list (μόνο αριθμούς από 18 έως 120), όχι black-list (απαγόρευση του "0", "-1", "999999").

Κανονικές εκφράσεις — δύναμη και κίνδυνος

Οι κανονικές εκφράσεις είναι ένα αποτελεσματικό εργαλείο για τον έλεγχο μορφής, αλλά μπορούν να αποτελέσουν πηγή επιθέσεων ReDoS (Regular Expression Denial of Service). Ορισμένα πρότυπα (για παράδειγμα, το (a+)+b) οδηγούν σε καταστροφικό backtracking σε μεγάλες συμβολοσειρές, φορτώνοντας πλήρως τον επεξεργαστή του διακομιστή. Χρησιμοποιήστε δοκιμασμένες βιβλιοθήκες regex και περιορίστε το μήκος της συμβολοσειράς πριν την εφαρμογή της κανονικής έκφρασης. Για πολύπλοκες περιπτώσεις (email, URL) χρησιμοποιήστε τους ενσωματωμένους αναλυτές των γλωσσών, όχι αυτοσχέδιες κανονικές εκφράσεις.

Τυπικά λάθη κατά τον έλεγχο

Ακόμη και έμπειροι προγραμματιστές κάνουν λάθη κατά την υλοποίηση του ελέγχου. Τα πιο συχνά: έλεγχος μόνο στην πλευρά του πελάτη, πολύ αυστηροί κανόνες (κωδικός πρόσβασης "Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters"), μη ενημερωτικά μηνύματα σφαλμάτων ("Error: invalid input") και αγνόηση ακραίων περιπτώσεων (κενά στην αρχή/στο τέλος, χαρακτήρες Unicode, κενές συμβολοσειρές). Καθένα από αυτά τα λάθη υποβαθμίζει την UX και μπορεί να μειώσει τη μετατροπή φορμών.

• Μόνο έλεγχος στην πλευρά του πελάτη — το πιο επικίνδυνο λάθος: κάθε αίτημα μπορεί να πλαστογραφηθεί μέσω Postman ή cURL
• Πολύ αυστηροί κανόνες — απομακρύνουν τους χρήστες: το OWASP συνιστά ελάχιστες απαιτήσεις κατά την εγγραφή
• Αγνόηση Unicode — ο έλεγχος του μήκους συμβολοσειράς σε bytes (όχι σε χαρακτήρες) σπάει τα ελληνικά, τα κινεζικά, τα emoji
• Μη ενημερωτικά σφάλματα — "Invalid format" αντί για "Email must contain @ symbol after local part"
• Έλεγχος κενού πεδίου — το if (value) δεν διακρίνει την κενή συμβολοσειρά από το μηδέν, το false ή το "0"

Η βέλτιστη πρακτική — ένα συγκεντρωτικό σύστημα ελέγχου καλυμμένο με unit tests. Κάθε κανόνας πρέπει να δοκιμάζεται ξεχωριστά: οριακές τιμές, σωστά δεδομένα, τυπικές επιθέσεις (απόπειρες SQLi, XSS-payloads, πολύ μεγάλες συμβολοσειρές). Τα δοκιμαστικά παλινδρόμησης για τον έλεγχο αποτρέπουν την τυχαία αποδυνάμωση των κανόνων κατά τον ανασχηματισμό. Χρησιμοποιήστε property-based testing (QuickCheck, fast-check) για τη δημιουργία τυχαίων δεδομένων και τον έλεγχο ότι ο έλεγχος δεν αποτυγχάνει με εξαίρεση.