| Version 1 (modified by , 7 days ago) ( diff ) |
|---|
P9 – API Security (Input Validation, Rate Limiting, Auth Basics)
Overview
In real systems, the database is accessed through an API (backend). Because of that, protecting the API is just as important as designing the database correctly. In Wedding Planner, endpoints such as RSVP updates and booking availability must be protected from invalid input and abuse.
Input validation
Input validation means checking all user input before using it in SQL queries or inserting it in the database.
Why it matters:
- prevents incorrect data from being stored
- avoids broken constraints and invalid formats
- reduces risk of attacks (SQL injection, malicious payload)
Example connected to our project: When calling:
/availability/venue?venue_id=1&date=2026-06-20&start=15:00&end=21:00
The API should validate:
- venue_id is numeric
- date is valid YYYY-MM-DD
- start/end are valid HH:MM
- end_time > start_time
Pseudo-code example:
if not venue_id.isdigit(): return error("Invalid venue_id")
if not valid_date(date): return error("Invalid date format")
if end <= start: return error("Invalid interval")
Rate limiting
Rate limiting protects the system from too many requests in a short time (spam / brute force).
Why it matters in Wedding Planner:
- availability checks can be called many times
- attacker can overload API by repeatedly calling /availability/venue
- database performance becomes worse under heavy traffic
Example rule:
- max 60 requests per minute per user/IP
Pseudo-config (conceptual):
limit_requests("/availability/venue", 60 per minute)
Authentication basics
Authentication means verifying who the user is (login/session/token).
Even though our P4 prototype is minimal and REST-based, in a real system:
- only logged-in users should manage weddings
- only wedding owner should edit guests / RSVP
- users should not access other people’s weddings
Example access rule (connected to our project):
GET /weddings/1/guests
Should return data only if:
- user is logged in
- user owns wedding_id = 1
Pseudo-code:
if not authenticated(): return 401 if wedding.user_id != current_user.id: return 403
Conclusion
API security protects the database by ensuring that only valid and allowed requests reach the data layer. For Wedding Planner, input validation is critical for correctness (dates/times/IDs), rate limiting protects frequent endpoints like availability checks, and authentication ensures users can only access their own weddings. These practices would be mandatory in a real production implementation of the system.
