Wednesday, July 10, 2024

HTTP Cookies vs Sessions vs Tokens – Web Authentication & Authorization Explained

HTTP cookies:
  • HTTP cookies are small pieces of data that are sent by the server to the client, and stored by the browser.
  • They can be used to store user preferences, track user behavior, or maintain user sessions.
  • For authentication and authorization, cookies can store a unique identifier that links the user to a server-side record of their credentials and roles.
  • The browser sends the cookie back to the server with every request, so the server can verify the user's identity and permissions.
  • However, cookies have some drawbacks, such as being vulnerable to theft, forgery, or cross-site scripting attacks, and being limited by size and number.
HTTP sessions:
  • HTTP sessions are a way of maintaining stateful communication between the client and the server, despite HTTP being a stateless protocol.
  • Sessions use cookies or other methods to store a session ID on the client side and associate it with a server-side data structure that contains the user's information and state.
  • Sessions can store more data than cookies and can be more secure if the session ID is encrypted or regenerated frequently.
HTTP tokens:
  • HTTP tokens are another way of implementing stateless authentication and authorization, without relying on cookies or sessions.
  • Tokens are self-contained pieces of data that encode the user's identity, permissions, and other claims, and are signed by the server using a secret key or a public-private key pair.
  • Tokens are sent by the server to the client, and stored by the browser in local storage or memory.
  • The client sends the token back to the server with every request, and the server validates the token's signature and payload.
  • Tokens can be more flexible, portable, and scalable than cookies or sessions, and can support cross-domain and cross-origin requests.
Cookie-based vs Token-based authentication:
  • Cookie-based and token-based authentication are two common approaches to implementing web authentication and authorization, and each one has its own pros and cons.
  • Cookie-based authentication relies on the server to manage the user's session and state and uses cookies to store and transmit the session ID.
  • Token-based authentication relies on the client to store and transmit the user's information and claims and uses tokens to encode and sign them.
  • Cookie-based authentication can be simpler to implement, more compatible with browsers, and easier to revoke.
  • Token-based authentication can be more efficient, secure, and flexible, and support more scenarios and platforms.
How to choose the best method
  • When deciding which method is the best for web authentication and authorization, there is no definite answer as it depends on various factors such as the type, size, and complexity of the web application, the security and performance requirements, user experience and expectations, and available technologies and standards. Generally speaking, cookies should be used if stateful communication between the client and server is needed or if existing browser features and frameworks that support cookies are to be leveraged. Tokens should be used if stateless communication between the client and server is necessary or if cross-domain and cross-origin requests need to be enabled. A combination of cookies and tokens can be used to achieve a balance between statefulness and statelessness or to enhance the security and functionality of your web application.
  • Stateless Protocol does not require the server to retain the server information or session details. Stateful Protocol requires the server to save the status and session information.

Understanding HTTP Headers: Types, Examples & Their Role in Web Communication


HTTP Request and Response objects consist of a body and header. While the body in the Response holds the data message (HTML, JSON) or form fields in the Request, the headers let the client and the server pass essential information about each other.
Headers can be grouped into four categories by their context:
  • General headers contain information that is relevant for both request and Response, but no information about the data in a body.
  • Request headers hold information about the client and requested resources.
  • Response headers include server details, like time, location, and configuration.
  • Entity header informs the browser about the type and body of the resource.
Let’s inspect more in detail. Go to the webpage https://madurai.nic.in/, open the console > Network tab, and select the document to inspect headers. You will likely see the headers divided into General, Request, and Response.

General group consist of the following information:
Request Headers include the following properties:
  • Accept: / (Accept any content type)
  • Accept-Encoding: gzip, deflate, br, zstd (An algorithm, such as compression that is used on the recourse sent back.)
  • Accept-Language: en-US, en (Hints the server about the expected language)
  • Connection: keep-alive (Controls how long connection should stay open)
  • User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36 (Lets server to identify the characteristics of the application, OS, vendor, and versions)
Response Headers include:
  • Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 (Set the instruction for caching. Other setting types: no-cache, no-store, no-transform)
  • Content-Encoding: Specifies the compression algorithm used for the response body
  • Content-Length: 17 (The size of the recourse in bytes)
  • Content-Type: application/json; charset=UTF-8 (The resource type received. The current type is a JSON document.)
  • Date: Tue, 09 Jul 2024 06:57:27 GMT (The time when the message was created)
  • Expires: Wed, 11 Jan 1984 05:00:00 GMT (Sets the date when the relevant content will no longer be new/fresh)
  • Server: Specifies the software used by the server at the time of the sent Response

Tuesday, July 9, 2024

Low Severity and High Priority Bugs in E-commerce Web Application

1. Typo on the Checkout Confirmation Page
Description: A misspelled word on the checkout confirmation page.
Severity: Low
Priority: High

2. Logo Displaying Incorrectly on Homepage
Description: The company logo appears stretched or pixelated.
Severity: Low
Priority: High

3. Incorrect Customer Support Email Address on the Contact Us Page
Description: The email address provided for customer support is incorrect.
Severity: Low
Priority: High

4. Broken Social Media Links in Footer
Description: Links to social media pages in the footer are broken.
Severity: Low
Priority: High

5. Non-functional Promo Code Input Box
Description: The input box for promo codes in the checkout process does not work.
Severity: Low
Priority: High

High Severity Low Priority Bugs in E-Commerce Web Application

1. Payment Gateway Failure in Specific Currency
High Severity: Users cannot complete purchases using a particular currency.
Low Priority: This currency is rarely used by the customer base.
Technical: When users select a rarely used currency, the payment gateway integration fails due to incorrect API calls or missing currency configuration.
Simple: Users can't pay in a specific, rarely-used currency.

2. Crash When Filtering Products by a Rare Attribute
High Severity: The website crashes, disrupting user experience.
Low Priority: The attribute filter is rarely used by customers.
Technical: Filtering by an uncommon attribute triggers a crash, possibly due to a null reference or unhandled exception.
Simple: The site crashes when filtering by a rarely used feature.

3. Incorrect Discount Calculation for Bulk Orders
High Severity: Users are charged incorrect amounts.
Low Priority: Bulk orders are rare.
Technical: The discount logic has a bug when calculating bulk order discounts, leading to incorrect pricing.
Simple: Bulk orders get the wrong discounts.

4. Failure to Load Product Images on Secondary Pages
High Severity: Product images do not load, affecting user experience.
Low Priority: Occurs on less frequently visited pages.
Technical: Image URLs or CDN issues prevent images from loading on less-visited pages.
Simple: Product images don't show up on certain pages.

5. Inability to Apply Multiple Coupons on Checkout
High Severity: Users cannot avail of multiple discounts.
Low Priority: Only a few users use multiple coupons.
Technical: The checkout process doesn't handle multiple coupon codes due to a bug in the discount application logic.
Simple: Users can't use more than one coupon at a time.

6. Error in Wishlist Functionality for Out-of-Stock Items
High Severity: Users cannot add out-of-stock items to their wishlist.
Low Priority: Out-of-stock items are a small portion of the catalogue.
Technical: The wishlist feature crashes or misbehaves when adding out-of-stock items due to lack of proper handling.
Simple: Can't add out-of-stock items to a wishlist.

7. Mismatch in Product Specifications on Detailed View
High Severity: Detailed view shows incorrect specifications.
Low Priority: Rarely visited detailed specifications page.
Technical: The product detail page shows incorrect specs due to outdated or incorrect data fetching logic.
Simple: Wrong details are shown on the product page.

8. Search Function Fails for Long Strings
High Severity: Users can't search with long keywords.
Low Priority: Most users use short search queries.
Technical: Long search queries cause database or server errors, possibly due to input length limits or inefficient query handling.
Simple: Searching with long phrases doesn't work.

9. Incorrect Display of User Loyalty Points
High Severity: Users see the wrong loyalty points balance.
Low Priority: The loyalty points program has low participation.
Technical: The loyalty points calculation or display logic has errors, showing incorrect balances.
Simple: Users see the wrong loyalty points balance.

10. Failure to Load Reviews for Products with No Reviews
High Severity: Page crashes if a product has no reviews.
Low Priority: Most products have at least one review.
Technical: The review section crashes when there are no reviews, likely due to poor handling of empty datasets.
Simple: Page crashes if there are no reviews.