Mass assignment σε APIs: πώς ένα επιπλέον πεδίο μπορεί να αλλάξει δεδομένα που δεν πρέπει

Σε πολλές web εφαρμογές, το backend παίρνει JSON από ένα request και το περνά απευθείας σε μοντέλο ή database update. Αυτό είναι βολικό, αλλά μπορεί να δημιουργήσει σοβαρό security bug.

Το mass assignment εμφανίζεται όταν ο χρήστης μπορεί να στείλει επιπλέον πεδία που ο developer δεν περίμενε, και η εφαρμογή τα αποθηκεύει ή τα χρησιμοποιεί.

Παράδειγμα

Ένα admin form επιτρέπει σε χρήστη να αλλάξει όνομα και τηλέφωνο:

{
  "name": "Νίκος",
  "phone": "2100000000"
}

Αν το API δέχεται αυτόματα όλα τα πεδία, ένας κακόβουλος χρήστης μπορεί να δοκιμάσει:

{
  "name": "Νίκος",
  "phone": "2100000000",
  "role": "admin",
  "isApproved": true
}

Αν το backend δεν έχει allowlist, μπορεί να αλλάξει πεδία που δεν υπήρχαν καν στη φόρμα.

Γιατί δεν αρκεί το frontend

Το UI μπορεί να μη δείχνει πεδίο role, αλλά ο χρήστης μπορεί να στείλει request χειροκίνητα. Το frontend δεν είναι security boundary.

Η προστασία πρέπει να είναι server-side:

• ποια πεδία επιτρέπεται να ενημερωθούν
• από ποιον ρόλο
• σε ποιο workflow state
• για ποιο object

Αν ένα πεδίο είναι κρίσιμο, δεν πρέπει να ενημερώνεται από generic update endpoint χωρίς ξεκάθαρο έλεγχο.

Allowlist αντί για blocklist

Το OWASP προτείνει allow-listing για προστασία από mass assignment. Δηλαδή το API δέχεται μόνο τα πεδία που έχουν δηλωθεί ρητά.

Πρακτικά:

• DTOs ανά endpoint
• schema validation
• explicit mapping από input σε model
• διαφορετικά endpoints για διαφορετικές ενέργειες
• απόρριψη άγνωστων πεδίων
• tests με extra malicious fields

Blocklist τύπου «μην επιτρέπεις role» είναι πιο αδύναμη, γιατί μπορεί να ξεχαστεί νέο κρίσιμο πεδίο στο μέλλον.

Σε CRM και portals

Το mass assignment είναι ιδιαίτερα επικίνδυνο σε custom CRM και portals, γιατί τα objects έχουν πολλά εσωτερικά πεδία.

Παραδείγματα πεδίων που δεν πρέπει να αλλάζει ο απλός χρήστης:

• ownerId
• tenantId
• role
• status
• discountPercent
• approvedAt
• isPaid
• internalNotes

Αυτά πρέπει να αλλάζουν μόνο από συγκεκριμένες ροές και ρόλους.

Πώς το κάνει η Ai Foundry

Στην Ai Foundry σχεδιάζουμε APIs και admin forms με explicit contracts. Δεν αφήνουμε γενικά payloads να ενημερώνουν εσωτερικά μοντέλα χωρίς έλεγχο. Ορίζουμε schemas, DTOs, authorization rules και business logic ανά endpoint.

Σε CRM, portals, e-shop workflows και AI automations, αυτό μειώνει το ρίσκο να αλλάξουν κρίσιμα δεδομένα από λάθος request ή λάθος integration. Η ασφάλεια ξεκινά από το πώς περνά το input στο backend.

Checklist

Ελέγξτε:

• αν τα APIs δέχονται άγνωστα πεδία
• αν γίνεται explicit mapping από input σε model
• αν υπάρχουν DTOs ή schemas ανά endpoint
• αν κρίσιμα πεδία αλλάζουν μόνο από ειδικές ροές
• αν authorization ελέγχεται πριν το update
• αν υπάρχουν tests με extra fields
• αν admin-only πεδία δεν περνούν από public forms

Το mass assignment είναι ύπουλο γιατί η εφαρμογή φαίνεται να δουλεύει σωστά. Το πρόβλημα εμφανίζεται όταν κάποιος στείλει κάτι που το UI δεν θα έστελνε ποτέ.