Changes between Version 2 and Version 3 of P9APISecurity


Ignore:
Timestamp:
01/13/26 20:03:41 (7 days ago)
Author:
193284
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • P9APISecurity

    v2 v3  
    22
    33=== Overview ===
    4 In a real Wedding Planner web application, the API is the main entry point for all user actions (view weddings, RSVP, guest management, availability checks).
    5 If API endpoints are not protected, attackers can abuse them to read private data, spam requests, or modify bookings.
     4In a real Wedding Planner web application, the REST API is the main entry point for all actions (view weddings, manage guests, RSVP, bookings, availability checks).
     5If API endpoints are not protected, malicious users can read private data, spam requests, or attempt to modify reservations.
    66
    7 Even though our P4 prototype is minimal (Flask REST + SQLite), the same security principles would apply in a production version.
     7Even though our P4 prototype is minimal (Flask REST + SQLite), the same security principles apply in a production environment.
    88
    99=== Main risks for our API ===
    10 If 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)
     10If API security is missing, common risks include:
     11 * Unauthorized access to private wedding data (guests, RSVP responses, attendance info)
     12 * Fake RSVP/attendance spam (polluting the database)
     13 * Endpoint abuse (especially availability checks)
    1414 * SQL injection attempts through query parameters
    1515
     16In Wedding Planner, the most sensitive resources are:
     17 * Guest lists (Guest table)
     18 * RSVP responses (Event_RSVP table)
     19 * Bookings (Venue_booking, Band_booking, Photographer_booking)
     20
    1621=== Input validation (most important rule) ===
    17 Input validation means checking every value that comes from the user before using it.
    18 In 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)
     22Input validation means checking every parameter received from the user before using it in business logic or database queries.
     23This prevents invalid requests, inconsistent data, and accidental crashes.
    2224
    23 Example 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
     25In our project, validation is especially important for:
     26 * wedding_id, event_id, guest_id (must be positive integers)
     27 * date, start_time, end_time (must be valid formats)
     28 * RSVP status (must be an allowed value)
     29
     30Example validation rules:
     31 * wedding_id > 0
     32 * end_time > start_time
     33 * RSVP status ∈ {accepted, declined, pending}
    2734
    2835Example (pseudo-code):
    2936{{{
    3037if wedding_id <= 0:
    31     return error "Invalid wedding_id"
     38    return 400 "Invalid wedding_id"
    3239
    3340if end_time <= start_time:
    34     return error "Invalid time interval"
     41    return 400 "Invalid time interval"
    3542}}}
    3643
    3744Why this matters:
    38 Without validation, invalid input can crash the API or create inconsistent data (wrong bookings, duplicates, broken rows).
     45Without validation, we can store broken bookings (wrong times) or invalid RSVP values that affect attendance logic.
    3946
    40 === Parameterized queries (protection from SQL injection) ===
    41 SQL injection happens when attacker input becomes part of the SQL query.
    42 The safe way is to use parameterized queries, never string concatenation.
     47=== Parameterized queries (SQL injection prevention) ===
     48SQL injection happens when untrusted input becomes part of an SQL query.
     49The correct protection is to always use parameterized queries (never string concatenation).
    4350
    4451Unsafe example:
    … …  
    4754}}}
    4855
    49 Safe example:
     56Safe example (conceptual):
    5057{{{
    51 SELECT * FROM wedding WHERE wedding_id = %s;
     58SELECT * FROM wedding WHERE wedding_id = ?;
    5259}}}
    5360
    54 In Wedding Planner this is important for endpoints like:
     61This is critical for endpoints like:
    5562 * /weddings/<wedding_id>/events
    5663 * /weddings/<wedding_id>/guests
    57  * /availability/venue?venue_id=...&date=...
     64 * /availability/venue?venue_id=...&date=...&start=...&end=...
    5865
    59 === Basic authentication & authorization ===
    60 In a full production application, not everyone should access everything.
     66If these endpoints use unsafe query building, attackers can try inputs like:
     67{{{
     68wedding_id = "1 OR 1=1"
     69}}}
     70which can expose data from multiple weddings.
     71
     72=== Authentication & Authorization (access control basics) ===
     73In a full system, not every user should have access to all weddings.
    6174
    6275Authentication = who is the user?
    … …  
    6477
    6578Example 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
     79 * Only the owner of the wedding (User.user_id) can view/edit that wedding
     80 * Guests can only RSVP for events they are invited to
     81 * Only wedding owner can view full guest list
    6982
    70 Example check (conceptual):
     83Example authorization check (pseudo-code):
    7184{{{
    7285if current_user.user_id != wedding.user_id:
    … …  
    7487}}}
    7588
    76 This prevents a user from accessing another user's wedding details just by changing the wedding_id in the URL.
     89This prevents the common issue where a user changes the wedding_id in the URL to access another person’s data.
    7790
    78 === Rate limiting (prevent abuse) ===
    79 Rate limiting limits the number of requests per user/IP per minute.
    80 This is crucial for endpoints that can be abused.
     91=== Rate limiting (prevent endpoint abuse) ===
     92Rate limiting controls the number of requests per user/IP per time window.
     93This prevents spam, brute-force attempts, and performance degradation.
    8194
    82 In our system the most "abusable" endpoint is:
     95In Wedding Planner, the most “abusable” endpoint is:
    8396 * /availability/venue
    8497
    8598Attack scenario:
    86 Someone sends thousands of availability checks -> server slows down or crashes.
     99An attacker sends thousands of availability checks per minute which may overload the server.
    87100
    88101Example policy:
    89  * max 60 requests per minute per IP for /availability/venue
     102 * 60 requests/minute per IP for /availability/venue
     103 * 30 requests/minute for RSVP-related endpoints
    90104
    91 This keeps the API stable even under heavy traffic.
     105This keeps the system responsive and stable under heavy traffic.
    92106
    93 === How this connects to our project ===
    94 For 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
     107=== Practical examples connected to Wedding Planner ===
     108The following protections directly apply to our system:
     109 * Validate time interval and date format for venue bookings
     110 * Reject RSVP status outside allowed values
     111 * Limit repeated calls to availability endpoint
     112 * Ensure wedding owner can access guest list and attendance overview
     113
     114Example: protect guest list endpoint
     115 * /weddings/<wedding_id>/guests
     116Rules:
     117 * wedding_id must be valid integer
     118 * current_user must be wedding owner
     119 * SQL query must be parameterized
    99120
    100121=== Conclusion ===
    101 API security is essential even for a minimal prototype, because it demonstrates how the system would behave in real-world conditions.
    102 For our Wedding Planner application, the most important protections are input validation, parameterized queries, basic access control, and rate limiting.
    103 These practices prevent common attacks (SQL injection, data leaks, endpoint abuse) and ensure the system remains stable and trustworthy.
     122API security is essential because it protects the database and prevents abuse of the core system functionalities.
     123For the Wedding Planner system, the most important measures are strict input validation, parameterized queries, access control (auth/authorization), and rate limiting.
     124These practices prevent the most common attacks (SQL injection, data leaks, spam) and ensure the application remains stable and trustworthy.