Changes between Version 3 and Version 4 of OtherTopics

Timestamp:

06/01/26 23:19:33 (3 weeks ago)

Author:

181201

Comment:

--

OtherTopics

@@ -552 +552 @@
 With this index, we eliminated the expensive sequential scan in exchange for a highly efficient index scan. The query is still bottlenecked by `AVG(rating)`, this index provides a crucial performance improvement to the search feature, so we will '''keep''' it.
 
+
+== Security ==
+
+=== 1. Password Security (BCrypt) ===
+User passwords are encrypted before being stored in the database using {{{BCryptPasswordEncoder}}}. This ensures that even in the event of a database breach, plain-text passwords remain unreadable and are protected against brute-force and dictionary attacks. Authentication is securely handled by verifying the raw input against the stored BCrypt hash within the {{{UserService}}}.
+
+Implementation in {{{UserService.java}}}:
+{{{#!java
+    private final BCryptPasswordEncoder passwordEncoder = new BCryptPasswordEncoder();
+
+    @Transactional(readOnly = true)
+    public User authenticate(String username, String password) {
+        User user = userRepository.findByUsername(username).orElse(null);
+        if (user != null && passwordEncoder.matches(password, user.getPassword())) {
+            return user;
+        }
+        return null;
+    }
+
+    @Transactional
+    public User registerUser(String username, String password, String firstName, String lastName, String email, String role) {
+        // ...
+        newUser.setUsername(username);
+        newUser.setPassword(passwordEncoder.encode(password));
+        newUser.setFirstName(firstName);
+        // ...
+    }
+}}}
+
+=== 2. SQL Injection Prevention ===
+The application utilizes '''Spring Data JPA''' for all database interactions. By relying on JPA's built in repository methods, all user inputs are automatically treated as parameters rather than executable SQL strings. This protects the application from SQL Injection attacks.
+
+Example of safe repository usage in {{{UserService.java}}}:
+{{{#!java
+    @Transactional(readOnly = true)
+    public User authenticate(String username, String password) {
+        User user = userRepository.findByUsername(username).orElse(null);
+        // ...
+    }
+}}}
+
+=== 3. Role based access control (RBAC) ===
+The application implements strict endpoint protection based on user roles (Admin, PetOwner, PetSitter). Controller routes verify the identity and specific subtype of the authenticated user via the {{{HttpSession}}}. If an unauthorized role attempts to access restricted areas, they are immediately redirected, preventing privilege escalation.
+
+Implementation example in {{{AdminController.java}}}:
+{{{#!java
+    @GetMapping("/admin/users")
+    public String showAllUsers(HttpSession session, Model model) {
+        User user = (User) session.getAttribute("loggedInUser");
+        
+        if (user == null || user instanceof PetOwner || user instanceof PetSitter) {
+            return "redirect:/dashboard";
+        }
+        
+        List<User> users = userRepository.findAll();
+        model.addAttribute("users", users);
+        // ...
+        return "admin-users";
+    }
+}}}
+
+----
+
+== Not applicable ==
+
+During the security analysis phase, two common web security measures were evaluated but found to be inapplicable for our specific architecture:
+
+=== JWTs ===
+'''JSON Web Tokens''' are designed for Stateless REST APIs (for example, when using a completely separate React/Vue frontend). 
+
+Because our application uses a '''Server Side Rendering - SSR ''' architecture returning HTML views directly from controllers, we manage state using the built-in {{{HttpSession}}}. Session based authentication is the standard for this specific architecture and provides excellent security. Implementing JWTs would require an unnecessary and highly complex rewrite of our entire authentication system, moving away from SSR best practices.
+
+=== CORS  ===
+
+Because our frontend and backend are served together from the exact same Spring Boot instance, they share the exact same origin. Therefore, cross origin requests do not occur, making CORS configuration unnecessary for our application.