Security Architecture and Data Protection in BodegaX

BodegaX applies a defence-in-depth security model across every layer of the stack. The Angular frontend enforces route-level access control through injectable guards, stores session state exclusively in sessionStorage, and filters UI elements by role. The Spring Boot backend validates JWT tokens on every protected endpoint, hashes passwords with bcrypt, encrypts sensitive data with AES-256, and defends against SQL injection, XSS, and CSRF at the API boundary. Together these controls satisfy the non-functional security requirements defined in the project specification.

Authentication & Session Management

BodegaX uses session-based state management on the client backed by JWT authentication on the Spring Boot backend. When a user successfully logs in, the Angular frontend persists a session object in sessionStorage under the key 'bodegax'. JWT validation is handled entirely by the backend; the Angular source does not store or forward a JWT token — it passes user identity via body fields (such as uuid_admin and uuid_cliente) on subsequent API requests.

Session Object Structure

{
  "uuid":      "<user-uuid>",
  "nombre":    "<display-name>",
  "role":      "<admin | user>",
  "id":        "<numeric-id>",
  "direccion": "<address>"
}

This object is read throughout the application to drive role-based UI rendering and to attach identity information to outbound API request bodies. On logout, it is completely removed from sessionStorage and the relevant BehaviorSubject observables are reset to their default unauthenticated state:

sessionStorage.removeItem('bodegax');

The API base URL in the current frontend source is set to http://localhost:8080. This unencrypted HTTP address is only appropriate for local development. Before deploying to any staging or production environment, every API call must be updated to an https:// endpoint. Transmitting credentials or session identifiers over plain HTTP exposes them to interception.

Route Guards

Angular’s CanActivate interface is used to intercept navigation events before any protected component renders. BodegaX ships with two complementary guards.

`CheckLoginGuard` — Protects Authenticated Routes

This guard subscribes to the AppService.isLogged$ observable. If the user is not authenticated, navigation is blocked and the router redirects to /login. Here is the complete implementation from the source:

import { Injectable } from "@angular/core";
import { CanActivate, Router } from "@angular/router";
import { AppService } from "../../app.service";
import { Observable } from "rxjs";

@Injectable({
    providedIn: 'root'
})
export class CheckLoginGuard implements CanActivate {
    constructor(private appSvc: AppService, private router: Router) { }

    canActivate(): Observable<boolean> {
        return new Observable<boolean>((o) => {
            this.appSvc.isLogged$.subscribe(r => {
                if (r == false) {
                    this.router.navigate(['/login']);
                    o.next(false);
                    o.complete();
                } else {
                    o.next(true);
                    o.complete();
                }
            });
        });
    }
}

`CheckNotLoginGuard` — Protects Public Routes

The companion guard prevents already-authenticated users from accessing the login page. If a logged-in user attempts to navigate to /login, they are redirected back to their dashboard. This prevents session duplication.

If BodegaX is ever migrated from sessionStorage to cookie-based session management, make sure each cookie is set with both the Secure flag (HTTPS-only transmission) and the HttpOnly flag (inaccessible to JavaScript). This eliminates the XSS attack surface for session hijacking. SameSite=Strict or SameSite=Lax should also be set to prevent CSRF token leakage.

Role-Based Access Control

The role field stored in the session object drives access control at the UI level. Administrators see the full management interface — inventory entry, user administration, order dispatch, and configuration panels. Standard users see only the order placement and sales history views.

Administrator Role

Full access to inventory management, user creation and deactivation, order dispatch, sales reporting, and system configuration.

User Role

Restricted to viewing current stock, submitting orders, and reviewing their own sales history. Administrative UI elements are hidden.

Role enforcement at the UI level is a convenience measure. The Spring Boot backend independently enforces authorization on every API endpoint — role claims embedded in the JWT are validated server-side, so a client-side role bypass would still be rejected by the API.

Password Security

All user passwords are hashed with bcrypt on the Spring Boot backend before being persisted to PostgreSQL. bcrypt is an adaptive one-way function: the cost factor can be increased as hardware improves, keeping brute-force attacks computationally expensive. Plaintext passwords are never stored or logged. The user creation flow sends the password field to the backend over the API:

this.http.post("http://localhost:8080/admin/create", {
  role: "user",
  nombre: this.username,
  id: this.id,
  password: this.password,
  direccion: this.address,
});

The backend receives this payload and runs it through bcrypt before the INSERT or UPDATE query executes. Note that there is no Authorization header set in these calls — the Angular frontend does not attach Bearer tokens; JWT validation is a server-side concern.

Data Encryption

AES-256 at Rest

Sensitive data stored in PostgreSQL is encrypted using AES-256. This satisfies requirement RNF08 and the security constraint RS02, ensuring that even direct database access does not expose readable personal or financial data. This is a backend responsibility.

bcrypt for Passwords

User passwords are individually salted and hashed via bcrypt before persistence. This satisfies RS02 and ensures that a database breach does not compromise user credentials. This is a backend responsibility.

Transport Security

Environment	Protocol	Status
Production	HTTPS (TLS)	Required — satisfies RS03
Development (localhost)	HTTP	Acceptable only for local builds

Requirement RS03 mandates HTTPS for all client-to-server communication in non-development environments. When deploying to GCP Cloud Run or AWS, place an HTTPS load balancer or API Gateway in front of the Spring Boot service and configure Angular’s environment files to use the https:// base URL.

Attack Surface Protections

The following protections are implemented at the backend and satisfy requirement RNF09:

SQL Injection

Spring Boot uses JPA/Hibernate with parameterized queries and prepared statements. User-supplied values are never concatenated directly into SQL strings, neutralizing injection vectors.

XSS

Angular’s template engine escapes all dynamic content by default. Data bound into the DOM via {{ }} interpolation is HTML-escaped, preventing injected scripts from executing.

CSRF

The backend enforces CSRF protection on all state-changing endpoints. The Angular frontend does not use cookies or Authorization headers for session transport — identity is passed via request body fields — which further limits the traditional CSRF attack surface.

Account Lockout (Planned)

Test case AU-04 specifies that 5 consecutive failed login attempts should trigger a temporary account lock. This is a backend requirement (Spring Boot) and is not present in the current Angular frontend source.

Non-Functional Security Requirements

The following requirements are drawn directly from the project specification:

ID	Requirement	Status
RNF07	All users authenticate with secure credentials and hold appropriate permissions	✅ Implemented
RNF08	Sensitive information stored with AES-256 encryption	✅ Backend requirement
RNF09	Protection against SQL injection, XSS, and CSRF attacks	✅ Implemented
RS01	System access requires authentication	✅ Enforced via guards
RS02	Passwords hashed with bcrypt; sensitive data encrypted with AES-256	✅ Backend requirement
RS03	HTTPS required for all client-server communication	⚠️ Required for production
RS04	Compliance with Ley 1581 de 2012 on personal data protection	✅ See Legal page

Performance Security

The system is designed to handle up to 500 concurrent authenticated users while maintaining a 2-second maximum response time (constraint RR01/RR02). These thresholds are defined in the project specification and are recommended to be validated by JMeter load tests. Exceeding capacity limits could open denial-of-service risk; horizontal scaling via GCP Cloud Run or AWS ECS is the recommended mitigation.

Security FAQ

Where is the user session stored and how is it cleared?

The session is stored in the browser’s sessionStorage under the key 'bodegax'. It contains the user’s UUID, display name, role, numeric ID, and address. On logout, sessionStorage.removeItem('bodegax') is called, completely removing the object, and the application’s BehaviorSubject observables are reset to their unauthenticated defaults. Because sessionStorage is scoped to the browser tab and cleared when the tab is closed, there is no persistent token left on the device after a session ends.

Does the Angular frontend send JWT tokens in request headers?

No. The Angular frontend does not set Authorization or Bearer headers on any HTTP request, and no HttpInterceptor exists in the source to do so. JWT validation is handled entirely on the Spring Boot backend. The Angular application passes user identity to the API via body fields such as uuid_admin and uuid_cliente. This means the frontend treats the backend’s authentication mechanism as opaque — it relies on the session object stored in sessionStorage for local state decisions.

What happens if a user tries to access a protected route without logging in?

CheckLoginGuard intercepts the navigation event before the target component loads. It subscribes to AppService.isLogged$; if the value is false, the guard calls router.navigate(['/login']), emits false on the observable, and completes — so the protected component never renders and no data is exposed.

How are administrator and user permissions separated?

Role separation operates at two levels. On the frontend, the Angular application reads the role field from the session object and conditionally renders or hides administrative UI elements. On the backend, every Spring Boot endpoint that performs administrative actions validates the role claim embedded in the incoming JWT. A client-side bypass would be rejected by the API with a 403 Forbidden response.

Is bcrypt alone sufficient for password protection?

bcrypt is the industry-standard algorithm for password storage and is considered sufficient when an adequate cost factor is configured. BodegaX complements bcrypt storage with transport encryption (HTTPS in production). An account lockout policy (AU-04) is specified as a backend requirement to block brute-force attacks at the login endpoint but is not yet confirmed as implemented in the current codebase.

What data privacy laws does BodegaX comply with?

BodegaX is designed to comply with Ley 1581 de 2012 (Colombia’s personal data protection law), Ley 1266 de 2008 (Hábeas Data), and the GDPR (EU General Data Protection Regulation) where applicable. These laws govern the collection, storage, and processing of personal data such as user names, IDs, and addresses. See the Legal page for full compliance details.

Setup & Deployment

API Reference

Quality & Compliance

Security Architecture and Data Protection in BodegaX

Authentication & Session Management

Session Object Structure

Route Guards

`CheckLoginGuard` — Protects Authenticated Routes

`CheckNotLoginGuard` — Protects Public Routes

Role-Based Access Control

Administrator Role

User Role

Password Security

Data Encryption

AES-256 at Rest

bcrypt for Passwords

Transport Security

Attack Surface Protections

SQL Injection

XSS

CSRF

Account Lockout (Planned)

Non-Functional Security Requirements

Performance Security

Security FAQ

Build docs developers (and LLMs) love

Setup & Deployment

API Reference

Quality & Compliance

Documentation Index

​Authentication & Session Management

​Session Object Structure

​Route Guards

​CheckLoginGuard — Protects Authenticated Routes

​CheckNotLoginGuard — Protects Public Routes

​Role-Based Access Control

Administrator Role

User Role

​Password Security

​Data Encryption

AES-256 at Rest

bcrypt for Passwords

​Transport Security

​Attack Surface Protections

SQL Injection

XSS

CSRF

Account Lockout (Planned)

​Non-Functional Security Requirements

​Performance Security

​Security FAQ

Build docs developers (and LLMs) love

Authentication & Session Management

Session Object Structure

Route Guards

`CheckLoginGuard` — Protects Authenticated Routes

`CheckNotLoginGuard` — Protects Public Routes

Role-Based Access Control

Password Security

Data Encryption

Transport Security

Attack Surface Protections

Non-Functional Security Requirements

Performance Security

Security FAQ