Changes between Initial Version and Version 1 of P9APISecurity

Timestamp:

01/13/26 18:37:15 (7 days ago)

Author:

193284

Comment:

--

P9APISecurity

@@ +1 @@
+= 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.