Changes between Version 1 and Version 2 of P9APISecurity


Ignore:
Timestamp:
01/13/26 19:27:29 (7 days ago)
Author:
193284
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • P9APISecurity

    v1 v2  
    1 = P9 – API Security (Input Validation, Rate Limiting, Auth Basics) =
     1== API Security (Input validation, Rate limiting, Auth basics) ==
    22
    3 == Overview ==
    4 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.
    5 In Wedding Planner, endpoints such as RSVP updates and booking availability must be protected from invalid input and abuse.
     3=== Overview ===
     4In a real Wedding Planner web application, the API is the main entry point for all user actions (view weddings, RSVP, guest management, availability checks).
     5If API endpoints are not protected, attackers can abuse them to read private data, spam requests, or modify bookings.
    66
    7 == Input validation ==
    8 Input validation means checking all user input before using it in SQL queries or inserting it in the database.
     7Even though our P4 prototype is minimal (Flask REST + SQLite), the same security principles would apply in a production version.
    98
    10 Why it matters:
    11  * prevents incorrect data from being stored
    12  * avoids broken constraints and invalid formats
    13  * reduces risk of attacks (SQL injection, malicious payload)
     9=== Main risks for our API ===
     10If security is missing, possible problems include:
     11 * Unauthorized access to wedding data (guests, RSVPs, bookings)
     12 * Fake RSVPs / attendance spam
     13 * Availability endpoint abuse (hundreds of calls per second)
     14 * SQL injection attempts through query parameters
    1415
    15 Example connected to our project:
    16 When calling:
     16=== Input validation (most important rule) ===
     17Input validation means checking every value that comes from the user before using it.
     18In our system, this applies especially to parameters such as:
     19 * wedding_id, event_id, guest_id (must be integer)
     20 * date and time intervals for bookings (must be valid and logical)
     21 * RSVP status (must be only allowed values)
     22
     23Example validation rules in our project:
     24 * wedding_id must be a positive integer
     25 * end_time must be greater than start_time
     26 * RSVP status must be one of: accepted / declined / pending
     27
     28Example (pseudo-code):
    1729{{{
    18 /availability/venue?venue_id=1&date=2026-06-20&start=15:00&end=21:00
     30if wedding_id <= 0:
     31    return error "Invalid wedding_id"
     32
     33if end_time <= start_time:
     34    return error "Invalid time interval"
    1935}}}
    2036
    21 The API should validate:
    22  * venue_id is numeric
    23  * date is valid YYYY-MM-DD
    24  * start/end are valid HH:MM
    25  * end_time > start_time
     37Why this matters:
     38Without validation, invalid input can crash the API or create inconsistent data (wrong bookings, duplicates, broken rows).
    2639
    27 Pseudo-code example:
     40=== Parameterized queries (protection from SQL injection) ===
     41SQL injection happens when attacker input becomes part of the SQL query.
     42The safe way is to use parameterized queries, never string concatenation.
     43
     44Unsafe example:
    2845{{{
    29 if not venue_id.isdigit(): return error("Invalid venue_id")
    30 if not valid_date(date): return error("Invalid date format")
    31 if end <= start: return error("Invalid interval")
     46sql = "SELECT * FROM wedding WHERE wedding_id=" + wedding_id
    3247}}}
    3348
    34 == Rate limiting ==
    35 Rate limiting protects the system from too many requests in a short time (spam / brute force).
    36 
    37 Why it matters in Wedding Planner:
    38  * availability checks can be called many times
    39  * attacker can overload API by repeatedly calling /availability/venue
    40  * database performance becomes worse under heavy traffic
    41 
    42 Example rule:
    43  * max 60 requests per minute per user/IP
    44 
    45 Pseudo-config (conceptual):
     49Safe example:
    4650{{{
    47 limit_requests("/availability/venue", 60 per minute)
     51SELECT * FROM wedding WHERE wedding_id = %s;
    4852}}}
    4953
    50 == Authentication basics ==
    51 Authentication means verifying who the user is (login/session/token).
     54In Wedding Planner this is important for endpoints like:
     55 * /weddings/<wedding_id>/events
     56 * /weddings/<wedding_id>/guests
     57 * /availability/venue?venue_id=...&date=...
    5258
    53 Even though our P4 prototype is minimal and REST-based, in a real system:
    54  * only logged-in users should manage weddings
    55  * only wedding owner should edit guests / RSVP
    56  * users should not access other people’s weddings
     59=== Basic authentication & authorization ===
     60In a full production application, not everyone should access everything.
    5761
    58 Example access rule (connected to our project):
     62Authentication = who is the user?
     63Authorization = what is the user allowed to do?
     64
     65Example rules in Wedding Planner:
     66 * Only the wedding owner (User) can view/edit that wedding
     67 * Guests can only RSVP via invitation link (limited access)
     68 * Admin can manage venue data
     69
     70Example check (conceptual):
    5971{{{
    60 GET /weddings/1/guests
     72if current_user.user_id != wedding.user_id:
     73    return 403 Forbidden
    6174}}}
    6275
    63 Should return data only if:
    64  * user is logged in
    65  * user owns wedding_id = 1
     76This prevents a user from accessing another user's wedding details just by changing the wedding_id in the URL.
    6677
    67 Pseudo-code:
    68 {{{
    69 if not authenticated(): return 401
    70 if wedding.user_id != current_user.id: return 403
    71 }}}
     78=== Rate limiting (prevent abuse) ===
     79Rate limiting limits the number of requests per user/IP per minute.
     80This is crucial for endpoints that can be abused.
    7281
    73 == Conclusion ==
    74 API security protects the database by ensuring that only valid and allowed requests reach the data layer.
    75 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.
    76 These practices would be mandatory in a real production implementation of the system.
     82In our system the most "abusable" endpoint is:
     83 * /availability/venue
     84
     85Attack scenario:
     86Someone sends thousands of availability checks -> server slows down or crashes.
     87
     88Example policy:
     89 * max 60 requests per minute per IP for /availability/venue
     90
     91This keeps the API stable even under heavy traffic.
     92
     93=== How this connects to our project ===
     94For Wedding Planner, API security should focus on:
     95 * Validating booking parameters (date/time overlap)
     96 * Protecting RSVP and attendance updates from spam
     97 * Ensuring only wedding owners can view guest lists
     98 * Preventing abuse of availability checks with rate limiting
     99
     100=== Conclusion ===
     101API security is essential even for a minimal prototype, because it demonstrates how the system would behave in real-world conditions.
     102For our Wedding Planner application, the most important protections are input validation, parameterized queries, basic access control, and rate limiting.
     103These practices prevent common attacks (SQL injection, data leaks, endpoint abuse) and ensure the system remains stable and trustworthy.