DEV Community: Bartosz Pietrucha

The Ultimate Guide to Angular User Login and Registration (Cookies, JWT)

Bartosz Pietrucha — Mon, 01 Mar 2021 18:04:32 +0000

In this guide, we will design and implement a complete solution for user authentication including user login, registration, and account confirmation with the Angular framework. We will learn how to structure the application with a separate module responsible for the visual and logical parts of user authentication. The proposed approach will be robust and flexible to address the most demanding requirements in modern Web applications.

Apart from the frontend implementation of our use cases, we will compare different approaches for performing user authentication used in today's Web. We will discuss distinct scenarios for application deployment and find an appropriate and most secure approach for our needs. By the end of this tutorial, you will have a simple yet adaptable Angular login example, that you could tweak to your specific needs. The code will be written for Angular 2+ and relevant to all newer versions (including Angular 11), but the discussed concepts also apply for AngularJS authentication.

Application structure and solution design

To find a proper place in the application for implementing authentication features, we need to take a step back and think about Angular application architecture and modular design. Our application is going to be divided into feature modules, each composed of presentational and logical parts. Most of the code we will have for this tutorial will belong to AuthModule. This module will contain:

routable container components for login, signup, and confirmation page,
two router guards,
a couple of fine-grained services
routing configuration
http interceptor

The next application-wide consideration is top-level routing. We want to divide the application into authentication and application parts. This will simplify the routes tree and later on allow us to create two distinct router guards to apply proper route activation policies.

const routes: Routes = [
  { path: '', redirectTo: '/login', pathMatch: 'full' },
  {
    path: 'app',
    canActivate: [AppGuard],
    component: LayoutComponent,
    children: [
      { path: 'dashboard', component: DashboardComponent },
      { path: 'expenses', component: ExpensesComponent },
      { path: 'settings', component: SettingsComponent) }
    ]
  }
];

@NgModule({
  imports: [RouterModule.forRoot(routes)],
  exports: [RouterModule]
})
export class AppRoutingModule { }

Before jumping into implementation we need to answer the last very important question. Since HTTP protocol is a stateless request-response protocol, we need to have a way of maintaining the user's context after successful login. In this article, I will describe the two most used approaches: cookie-based sessions and self-contained tokens.

A cookie-based session is based on the user's context maintained on the server-side. Each context can be identified by a session identifier, which is randomly generated for each browser and placed in a cookie. When we use the HttpOnly flag on that cookie, we are preventing our system from cross-site scripting attacks but still, we need to think about cross-site request forgery attacks. The cookie-based approach is very handy when our frontend application and backend API are hosted on the same origin (the same domain and port). This is because of the fundamental rule of the Web Security model, Same-origin policy, that would not allow us to share the same cookies across multiple backends. In other words, cookies are scoped per single domain.

The second approach may be useful when our system is deployed on separate origins: the frontend application is hosted on a different domain than backend API. In this case, the requests from the frontend to the backend would be considered cross-origin requests, and the cookies set on the backend origin called third-party cookies. A third-party cookie is the same mechanism that is used by analytical and tracking systems and can be easily turned off in modern browsers. A lot of users opt-out of third-party cookies as they are concerned about their privacy on the Internet. Also, some browser vendors are putting major efforts into eradicating third-party cookies completely.

So what should we do in such a case? We can use another way of providing the user's context between requests - HTTP Authorization Header. This requires programmatic reading, storing, and attaching an authorization token transported via header (as opposed to cookies). Just to put us on the same page, remember that session-id used in cookies is also a token, but an opaque one - it does not convey any information and is just a key to retrieve the session on the server. Another type of token is called a self-contained token, which we can put the user's context inside of. In 2015 Internet Engineering Task Force standardized JSON Web Token (JWT) that can securely transport information between the parties. Thanks to a cryptographic signature we can assume that the content of the JWT is authentic and integral. A self-contained nature of JWT allows us to retrieve user context, like permissions and credentials, without a need to maintain the session on the server (think of serverless and Function-as-a-Service). We can also integrate with third-party services without the restrictions of the same-origin policy (for example Firebase or AWS Amplify). I covered a more detailed explanation of JSON Web Tokens here.

I believe that it is very important to understand the fundamental differences between these two mechanisms, before implementing user authentication in the application. You can also check out my YouTube videos exploring the differences between these two approaches and the ways JWT can be hacked. We will build our frontend able to utilize both session cookies and token authentication with JSON Web Tokens. I told you it would be flexible! 🤓

WARNING: Whenever you are using any kind of authorization token that you store in LocalStorage or IndexedDB (so it's accessible by JavaScript code) you are exposing the token to be hijacked via cross-site scripting attack. However, there are valid mitigation techniques, like Content Security Policy, Subresource integrity, and built-in frameworks' sanitization mechanisms, that (when applied properly!) reduce that risk to a negligible degree. That being said that risk is real, so you should pay enough attention to those security issues.

Detailed implementation

Login feature

Let's start with the UI part - login component template. Our approach for user authentication is based on the pair of email and password, so we need two input items in the template. Note that the second input has an attribute type="password", which instructs the browser to render a masked input element. We also make use of Angular Material to provide a nice look-and-feel to the user interface. Below you can find our login form example.

<form [formGroup]="loginForm">

  <div class="header">Login to your account</div>

  <mat-form-field>
    <input matInput type="email" id="email" placeholder="Email" autocomplete="off" formControlName="email" required>
  </mat-form-field>

  <mat-form-field>
    <input matInput type="password" id="password" placeholder="Password" autocomplete="off" formControlName="password" required>
  </mat-form-field>

  <div class="actions">
    <button mat-flat-button color="primary" type="submit" (click)="login()" [disabled]="!loginForm.valid">Login</button>
    <div class="separator">
      <span>OR</span>
    </div>
    <button mat-stroked-button type="button" routerLink="/signup">Sign up</button>
  </div>

</form>

Now the question is: how to take input values from the user to execute the login? To link the HTML form and input elements in the view with the component code we can utilize some directives from the Reactive Forms module. By using FormGroupDirective in this way [formGroup]="loginForm", we are telling Angular that there is a property loginForm in the component that should hold an instance of that form. We are using FormBuilder to create email and password instances of FormControl. Email control is also equipped with a built-in email validator.

@Component({
  selector: 'app-login',
  templateUrl: './login.component.html'
})
export class LoginComponent implements OnInit {

  loginForm: FormGroup;

  constructor(private authService: AuthService,
    private formBuilder: FormBuilder,
    private router: Router) { }

  ngOnInit() {
    this.loginForm = this.formBuilder.group({
      email: ['', Validators.email],
      password: ['']
    });
  }

  get f() { return this.loginForm.controls; }

  login() {
    const loginRequest: LoginRequest = {
      email: this.f.email.value,
      password: this.f.password.value
    };

    this.authService.login(loginRequest)
      .subscribe((user) => this.router.navigate([this.authService.INITIAL_PATH]));
  }

}

The next step is to execute the underlying requests to perform the actual login once the button is clicked. Since we want to handle both cookie-based sessions and JWT tokens, we are decoupling HTTP requests from handling logic with the AuthStrategy interface. Depending on the chosen mechanism the actual implementation of AuthStrategy is injected in AuthService. This is possible thanks to the config setting that dictates which implementation of AuthStrategy is used. Below you can find that interface with actual implementations for cookies and JWT. Note that the authStrategyProvider factory method is used to register the provider in AuthModule.

auth.strategy.ts

export interface AuthStrategy<T> {

  doLoginUser(data: T): void;

  doLogoutUser(): void;

  getCurrentUser(): Observable<User>;

}

export const AUTH_STRATEGY = new InjectionToken<AuthStrategy<any>>('AuthStrategy');

export const authStrategyProvider = {
  provide: AUTH_STRATEGY,
  deps: [HttpClient],
  useFactory: (http: HttpClient) => {
    switch (config.auth) {
        case 'session':
          return new SessionAuthStrategy(http);
        case 'token':
          return new JwtAuthStrategy();
      }
  }
};

session-auth.strategy.ts

export class SessionAuthStrategy implements AuthStrategy<User> {

  private loggedUser: User;

  constructor(private http: HttpClient) {}

  doLoginUser(user: User): void {
    this.loggedUser = user;
  }

  doLogoutUser(): void {
    this.loggedUser = undefined;
  }

  getCurrentUser(): Observable<User> {
    if (this.loggedUser) {
      return of(this.loggedUser);
    } else {
      return this.http.get<User>(`${config.authUrl}/user`)
        .pipe(tap(user => this.loggedUser = user));
    }
  }
}

jwt-auth.strategy.ts

export class JwtAuthStrategy implements AuthStrategy<Token> {

  private readonly JWT_TOKEN = 'JWT_TOKEN';

  doLoginUser(token: Token): void {
    localStorage.setItem(this.JWT_TOKEN, token.jwt);
  }

  doLogoutUser(): void {
    localStorage.removeItem(this.JWT_TOKEN);
  }

  getCurrentUser(): Observable<User> {
    const token = this.getToken();
    if (token) {
      const encodedPayload = token.split('.')[1];
      const payload = window.atob(encodedPayload);
      return of(JSON.parse(payload));
    } else {
      return of(undefined);
    }
  }

  getToken() {
    return localStorage.getItem(this.JWT_TOKEN);
  }
}

As you can see above when using cookies, we don't need to handle the session-id as it is automatically put into the cookie by the browser. In the case of a JWT token authentication, we need to store it somewhere. Our implementation is putting it into LocalStorage.

Finally, to glue things together, AuthService is calling doLoginMethod on AuthStrategy after the HTTP request is executed. Note, that the final subscription to the observable stream is attached in LoginComponent and handles the last step to redirect to the initial page after login.

@Injectable({
  providedIn: 'root'
})
export class AuthService {

  public readonly LOGIN_PATH = '/login';
  public readonly CONFIRM_PATH = '/confirm';
  public readonly INITIAL_PATH = '/app/dashboard';

  constructor(
    private router: Router,
    private http: HttpClient,
    @Inject(AUTH_STRATEGY) private auth: AuthStrategy<any>
  ) { }

  signup(user: User): Observable<void> {
    return this.http.post<any>(`${config.authUrl}/signup`, user);
  }

  confirm(email: string, code: string): Observable<void> {
    return this.http.post<any>(`${config.authUrl}/confirm?`, {email, code});
  }

  login(loginRequest: LoginRequest): Observable<User> {
    return this.http.post<any>(`${config.authUrl}/login`, loginRequest)
      .pipe(tap(data => this.auth.doLoginUser(data)));
  }

  logout() {
    return this.http.get<any>(`${config.authUrl}/logout`)
      .pipe(tap(() => this.doLogoutUser()));
  }

  isLoggedIn$(): Observable<boolean> {
    return this.auth.getCurrentUser().pipe(
      map(user => !!user),
      catchError(() => of(false))
    );
  }

  getCurrentUser$(): Observable<User> {
    return this.auth.getCurrentUser();
  }

  private doLogoutUser() {
    this.auth.doLogoutUser();
  }

}

The approach with AuthStrategy is making the AuthService implementation very flexible, but if you don't need it, it's totally fine to go without it. The image below illustrates the composition of the presented elements.

Sign-up feature

The signup component is very alike to the login component. We have a similar template code with form and inputs. The main difference is in what happens after a successful HTTP request. Here we are just redirecting to the confirmation page from ConfirmComponent.

signup.component.html

<form [formGroup]="signupForm">

  <div class="header">Create your account</div>

  <mat-form-field>
    <input matInput type="email" id="signup_email" placeholder="Email" autocomplete="new-password" formControlName="email" required>
  </mat-form-field>

  <mat-form-field>
    <input matInput type="password" id="signup_password" placeholder="Password" autocomplete="new-password" formControlName="password" required>
  </mat-form-field>

  <div class="actions">
    <button mat-flat-button color="accent" type="submit" (click)="signup()" [disabled]="!signupForm.valid">Sign up</button>
    <div class="separator">
      <span>OR</span>
    </div>
    <button mat-stroked-button routerLink="/login">Login</button>
  </div>

</form>

signup.component.ts

@Component({
  selector: 'signup',
  templateUrl: './signup.component.html',
  styleUrls: ['./../auth.scss']
})
export class SignupComponent implements OnInit {

  signupForm: FormGroup;

  constructor(private authService: AuthService,
    private formBuilder: FormBuilder,
    private router: Router) { }

  ngOnInit() {
    this.signupForm = this.formBuilder.group({
      email: ['', Validators.email],
      password: ['']
    });
  }

  get f() { return this.signupForm.controls; }

  signup() {
    this.authService.signup(
      {
        email: this.f.email.value,
        password: this.f.password.value
      }
    ).subscribe(() => this.router.navigate([this.authService.CONFIRM_PATH]));
  }

}

Also, notice that we are not using AuthStrategy here. Signup is just sending a new pair of login and password to the backend and informing about the need for account confirmation.

Account confirmation feature

After successful signup, the user is informed about an email sent to the email address. The email contains a special link with a confirmation code. This link points to the confirmation component page in the frontend application. The ConfirmComponent is designed to work in 2 modes: before confirmation and after successful confirmation. Look at the template below and notice the isConfirmed flag in the conditional statement.

confirm.component.html

<ng-container *ngIf="!isConfirmed; else confirmed">
  <div class="header">We've sent you a confirmation link via email!</div>
  <div>Please confirm your profile.</div>
</ng-container>

<ng-template #confirmed>
  <div class="header">Your profile is confirmed!</div>
  <button mat-flat-button color="primary" routerLink="/login">Login</button>
</ng-template>

What dictates the displayed content of the component is the boolean value set in ngOnInit.

confirm.component.ts

@Component({
  selector: 'confirm',
  templateUrl: './confirm.component.html',
  styleUrls: ['./confirm.component.scss']
})
export class ConfirmComponent implements OnInit {

  isConfirmed = false;

  constructor(private activeRoute: ActivatedRoute, private authService: AuthService) { }

  ngOnInit(): void {
    const email = this.activeRoute.snapshot.queryParams.email;
    const code = this.activeRoute.snapshot.queryParams.code;

    if (email && code) {
      this.authService.confirm(email, code)
        .subscribe(() => this.isConfirmed = true);
    }
  }

}

The last missing piece is just an HTTP request to send a pair of email and corresponding confirmation code to the backend in AuthService.

Auth.service.ts - confirm()

  confirm(email: string, code: string): Observable<void> {
    return this.http.post<any>(`${config.authUrl}/confirm?`, {email, code});
  }

After successful confirmation, the page displays an incentive to log in.

WARNING: Whenever you are using some parameters passed via a link (like confirmation code or password recovery code), you need to remember about Referer headers. Only in 2020 Chrome changed the default settings of Referrer-Policy to strict-origin-when-cross-origin. Without that setting (which you can adjust to your needs) all the requests for additional resources (like analytics, widgets, images, etc.) sent from that page were containing the full URL in the Referer header. For example, when you open the confirmation link and the page contains some third-party resources, the requests to fetch them are sent with the header with the full URL including the email and code. So as a means of prevention it's always important to set a proper Referrer-Policy in your application.

User object

We came to the point where our login and registration with confirmation features are ready. Now we need to add some missing pieces to our system. The question is: how does the frontend client know who is logged in or what role does that user have? Depending on the authentication mechanism (cookie-based or token-based) the way to retrieve that information is different. Since we already have a proper abstraction over these mechanisms we can make use of the AuthStrategy interface. The method getCurrentUser will provide us with an Observable of a User object.

user.ts

import { Account } from './account';
import { Role } from './types';

export class User {
  id?: string;
  accountId?: string;
  account?: Account;
  email?: string;
  password?: string;
  role?: Role;
  confirmed?: boolean;
  tfa?: boolean;
}

Look at the implementations in both approaches. In the case of server-side sessions, if there is no local copy of a logged user, we need to ask the backend and store it locally. In the case of a JWT token-based authentication, we just need to unwrap the information from inside the token. Since we just want the payload we need to split the string with token.split('.')[1] and window.atob function decodes the base64 format of the token.

session-auth.strategy.ts - getCurrentUser()

  getCurrentUser(): Observable<User> {
    if (this.loggedUser) {
      return of(this.loggedUser);
    } else {
      return this.http.get<User>(`${config.authUrl}/user`)
        .pipe(tap(user => this.loggedUser = user));
    }
  }

jwt-auth.strategy.ts - getCurrentUser()

  getCurrentUser(): Observable<User> {
    const token = this.getToken();
    if (token) {
      const encodedPayload = token.split('.')[1];
      const payload = window.atob(encodedPayload);
      return of(JSON.parse(payload));
    } else {
      return of(undefined);
    }
  }

  getToken() {
    return localStorage.getItem(this.JWT_TOKEN);
  }

Adapting UI

Since the logged user may have some specific role assigned we need to adapt the UI accordingly. Not only the specific routes are available or unavailable, but some elements should be displayed or not. We might manually ask for the user role every time we need to know if the element should be rendered with ngIf, but there is a smarter way. What I propose is to create a custom structural directive that needs a list of roles, for which a given element should be displayed. This would provide us with an elegant way of template composition. Look at the example below. The button will be displayed only in the currently logged user has a role 'owner'.

  <div class="add">
    <button mat-fab color="primary" (click)="openExpenseDialog()" *forRoles="['owner']">+</button>
  </div>

This is possible thanks to the forRoles structural directive implementation presented below.

import { Directive, Input, ViewContainerRef, TemplateRef } from '@angular/core';
import { AuthService } from '../services/auth.service';

@Directive({
  selector: '[forRoles]'
})
export class ForRolesDirective {

  roles: string[];

  @Input()
  set forRoles(roles: string[]|string) {
    if (roles != null) {
      this.roles = Array.isArray(roles) ? roles : [roles];
      this.roles = this.roles.map(r => r.toUpperCase());
    } else {
      this.roles = [];
    }

    this.authService.getUserRole$().subscribe(
      role => {
        if (role && !this.roles.includes(role.toUpperCase())) {
          this.viewContainer.clear();
        } else {
          this.viewContainer.createEmbeddedView(this.templateRef);
        }
      }
    );
  }

  constructor(
    private viewContainer: ViewContainerRef,
    private templateRef: TemplateRef<any>,
    private authService: AuthService) { }

}

Remember that the directive needs to be declared in an Angular module. In our case, we are declaring it in AuthModule and exporting it to be available to the outside world.

Protecting routes

Users' authorization and roles dictate not only UI elements' visibility. On the higher level, we need to restrict access to the application's routes. Thanks to our top-level routing and separation into authentication and application this task is very easy. We need Router Guards that govern the access to these 2 parts.

@Injectable({
  providedIn: 'root'
})
export class AppGuard implements CanActivate {

  constructor(private authService: AuthService, private router: Router) { }

  canActivate(): Observable<boolean> {
    return this.authService.isLoggedIn$().pipe(
      tap(isLoggedIn => {
        if (!isLoggedIn) { this.router.navigate(['/login']); }
      })
    );
  }
}

The logic in the AppGuard says: IF the user is not logged THEN redirect to the login page and do not allow access to the application part.

@Injectable({
  providedIn: 'root'
})
export class AuthGuard implements CanActivate {

  constructor(private authService: AuthService, private router: Router) { }

  canActivate(): Observable<boolean> {
    return this.authService.isLoggedIn$().pipe(
      tap(isLoggedIn => {
        if (isLoggedIn) {
          this.router.navigate([this.authService.INITIAL_PATH]);
        }
      }),
      map(isLoggedIn => !isLoggedIn)
    );
  }
}

On the other hand, the instruction in AuthGuard is just oposite: IF the user is logged in THEN do not allow to show the login page and redirect to the default page. We have seen how to register AppGuard already in main routing. Now, the next step is to register AuthGuard in AuthRoutingModule.

const routes: Routes = [
  {
    path: 'login', component: LoginComponent,
    canActivate: [AuthGuard]
  },
  {
    path: 'signup', component: SignupComponent,
    canActivate: [AuthGuard]
  },
  {
    path: 'confirm', component: ConfirmComponent,
    canActivate: [AuthGuard]
  }
];

@NgModule({
  imports: [RouterModule.forChild(routes)],
  exports: [RouterModule]
})
export class AuthRoutingModule { }

API requests authentication

The last element in our system is outgoing requests' authentication. When using cookies we don't need to do anything - session-id is attached in every HTTP query.

In the case of JSON Web Token, we need to have a dedicated code to add an Authentication header with a token to the requests. The handiest way is to use HttpInterceptor. Pay attention to the conditional check of the authentication mode - want to attach the token only if this is necessary.

@Injectable()
export class AuthInterceptor implements HttpInterceptor {

  constructor(private authService: AuthService, @Inject(AUTH_STRATEGY) private jwt: JwtAuthStrategy) { }

  intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {

    if (config.auth === 'token' && this.jwt && this.jwt.getToken()) {
      request = this.addToken(request, this.jwt.getToken());
    }

    return next.handle(request).pipe(catchError(error => {
      if (error.status === 401) {
        this.authService.doLogoutAndRedirectToLogin();
      }
      return throwError(error);
    }));

  }

  private addToken(request: HttpRequest<any>, token: string) {
    return request.clone({
      setHeaders: { 'Authorization': `Bearer ${token}` }
    });
  }

}

Lastly, the interceptor needs to be registered in the providers list in AuthModule as presented below.

@NgModule({
  declarations: [ ... ],
  exports: [ ... ],
  imports: [ ... ],
  providers: [
    {
      provide: HTTP_INTERCEPTORS,
      useClass: AuthInterceptor,
      multi: true
    },
    ...
  ]
})
export class AuthModule { }

Summary and next steps

Even though we have a complete and robust solution, there are plenty of enhancements we could implement in your system to improve its security.

First of all two-factor authentication (2FA) is becoming more and more relevant these days. Attackers are using different strategies to get unauthorized access to accounts like brute-force attacks, dictionary attacks, credential stuffing, session hijacking, and many more. One of the easiest ways to implement 2FA is with Google Authenticator, but this is out of this article's scope. Another way to increase the security of the login system is to throttle failed login attempts. This can be very tricky to implement because if we blindly block some user's login, attackers could be easily executing Denial-of-Service (DoS) for particular users (for example constantly using the wrong password in an automated way). There are smart solutions to prevent this to happen, like Device cookies and trusted clients.

Finally, our implementation does not have the very important feature of account recovery (password reset). The feature may be covered in future tutorials.

Is that solution secure?

Yes and no. To make things realistic we need to remember that there are plenty of security risks in Web applications. There are vulnerabilities like cross-site request forgery when using cookies, cross-site scripting when storing tokens in local storage, not to mention that JSON Web Tokens implementation on the backend is crucial to the system's security.

To build secure Web systems you need to understand the fundamentals of the Web Security model, common security vulnerabilities, and prevention methods. There is a lot to take care of on the frontend side of the application, but the most crucial work from the security perspective is done on the backend of the system. This will be covered in upcoming articles.

Final words

We learnt how to add a login system to an Angular application and create a fully-functional login and registration page. We analyzed the differences between cookie-based and stateless authentication with JSON Web Tokens and provided valid scenarios for both. You can find a full source code of the presented mechanisms in my Budget training application on GitHub.

If you like this content and want to learn more, I highly recommend you join the waiting list for WebSecurity Academy program or WebSecurity Tuesday to receive 2-minute bite-sized tips every week.

Let me know in the comments if you have any questions. Thanks for reading! 😎

Build BULLETPROOF 💣 applications

Bartosz Pietrucha — Wed, 13 Jan 2021 10:50:53 +0000

You build amazing Web applications that people love to use. They are fast and user-friendly. It's time to take security seriously. Web Security model and industry standards are complex and omitted by many developers. Let's upgrade your skills.

What is inside newsletter

Clickjacking, XSS, CSRF, Brute-force attacks, HTTP Headers, OWASP Top 10, hashing, salting, OAuth, cookies, JWT and much more! ⚡

What is the technology behind

It does not matter if you use Angular or React, Java or Node, Python or .NET. There are many (technology-agnostic) proven strategies to improve Web applications security.

Join here 👉 https://tuesday.websecurity-academy.com 👈

Role-based access control in Angular & Node

Bartosz Pietrucha — Wed, 21 Oct 2020 12:34:44 +0000

Role-based access control in Angular & Node

Design, implement and secure a full-stack role-based access control system in 60 minutes 👉 Register for free

What you'll learn:

The case of role-based application
Learn the essential design decisions and domain modeling for multi-user account system from the full-stack perspective

Managing permissions
We'll discuss different vectors of authorization for the described class of systems and provide a starting point for further design decisions

Designing a secure REST API
Learn proved recipes for designing REST API for user login, signup, and application's restricted areas that require proper authorization

UserAuth object
Discover a convenient mechanism to transport user's information and roles

Conditional components visibility
How do we adapt a Single Page Application for a given role of a currently logged user? Learn about useful techniques and tricks.

BONUS: Failed logins throttling
How to secure an application from brute force or dictionary attacks? Let's design and implement a login throttler!

⚡ Register for free ⚡

Web Security Checklist ✔

Bartosz Pietrucha — Thu, 15 Oct 2020 08:36:31 +0000

Howdy Dev Community! 🖐

Here you can find a list of all the most important security checks for your Web applications!

Not sure what all of these mean? 👉 Join Web Security experts mailing to learn more as every Tuesday I send out a cool Web Security tip or trick! 💌 Also, I will send you a clickable PDF version of this checklist. ✔

Let's build secure apps! 🚀

My last day at a corporate job in Dec 2019...

Bartosz Pietrucha — Tue, 07 Jul 2020 18:10:59 +0000

Hi, my name is Bartosz. I have spent 9 years working as a software engineer and 5 years at the university to get my Master's Degree in Computer Science.

👉 The photo presents my last day at a corporate job in December 2019.
Let me tell you a story...

When I was about 13 yo I learned about some strange craft called "programming". And I started learning. Later software engineering became my profession. It was a hell of a journey.

In 2017, I was invited to speak at the conference in Israel, where I could share some of my knowledge. And this started a period of traveling around the World (including countries like Russia, Colombia, Germany, Belgium to name a few) and teach a lot of people.

During that time I started creating a brand called Angular Academy. Writing blog posts, creating videos, webinars, and stuff like that. All of that happening "after hours", because I had a regular, corporate job. In 2019 I asked my readers if they would buy an online learning program from me.

And they did. Real people gave me real money because they trusted me. I decided to risk and leave a well paid and safe job.

Now, after successfully delivering my promise to those people in Feb 2020, I opened the next edition of Angular Enterprise Security Academy.

And people are joining. Wish me luck.

PS. This is just a piece of a very long story. Would you like to read more about it?

Angular Enterprise Security Academy is OPEN 🤩

Bartosz Pietrucha — Fri, 03 Jul 2020 13:45:29 +0000

Do you want to learn all you need about Web Security and implement a role-based enterprise-grade authorization in Angular and Node.js?

I am happy to announce that Angular Enterprise Security Academy is open!
During the upcoming 12 weeks, we will be working together with our group to

Have a solid understanding of the Web Security model
Know Web Security vulnerabilities and prevention methods
Implement a role-based authorization system in real-life application
Know how to secure Angular application and backend API

You can join here https://angular-academy.com/security and use exclusive DEV_TO_100 discount code to get 100$ off the price!

The idea is that students learn from the videos in their own time, and we meet on a weekly basis on live sessions to answer questions, review the code and overcome all challenges!

Let's meet there!

FREE 5-day Angular Security Mini-Academy

Bartosz Pietrucha — Thu, 11 Jun 2020 13:49:29 +0000

It's available now! FREE Angular Security Mini-Academy!

OVER 2 HOURS OF FREE LESSONS!

💥 Client-side security boundaries
💥 OWASP Top 10 explained
💥 Cross-site scripting attacks
💥 JSON Web Token (JWT) Hacking
💥 Role-based access control design

JOIN FOR FREE

OWASP Top 10 Security Vulnerabilities

Bartosz Pietrucha — Mon, 24 Feb 2020 08:20:54 +0000

We are all passionate Web developers, aren't we? 🤗
We build amazing, fast, user-friendly applications that help other people. We love to learn new things and use modern tools! But...

...are we paying enough attention to the security aspects of the applications we build? Are users safe to use our systems?

In this article, I want to give you a short and concise breakdown of OWASP Top 10, a standard awareness document for developers and web application security. The Open Web Application Security Project (OWASP) is a worldwide foundation that works to improve the security of software. OWASP Top 10 document presents the 10 most widely spread vulnerabilities in web applications today (yes, yes, we build web applications with Angular and we NEED to pay attention to it!). Many of us are also developing server-side backend (Full-stack devs for the win ⚡), so this email may contain very significant knowledge.

Here is a summary of the most important parts of OWASP Top 10, that you need to know as a web developer. Just 10 minutes read to be smarter than hackers! 😎

1) Injection 🧨
The application may be vulnerable to malicious code injection via many different inputs like query params.

SELECT * FROM accounts WHERE custID=' + request.getParameter("id") + '

If id param in the above example is not validated or sanitized properly and used directly in SQL query on the server-side, it could display all accounts instead of a proper one. This is a concern more for the server-side, but you should be aware of this as a web developer.

2) Broken Authentication 🧨
Many application users reuse the same logins and passwords across different websites. This creates a huge risk that allows hackers to perform so-called credential stuffing. If the attacker somehow gets a database of a different system (or uses data from well-know publicly available data-breach) he can use automated ways to seek for valid login/password pair and get access to the system. Hackers also may use brute-force or dictionary attacks to login to your system! 😵

But don't worry too much! There are some ways we can protect our applications from this kind of vulnerabilities like:

Multi-factor authentication MFA (using SMS, email, fingerprint, etc),
Password checking during registration (comparing passwords with passwords knowns from data-breaches),
Imposing password complexity rules (minimum length, special characters occurrence),
Limiting failed login attempts (for example, after 3 failed logins, disallow login for 1 hour).

3) Sensitive data exposure 🧨
Sensitive data like logins and passwords, credit card numbers, healthcare records require special treatment. It is crucial to:

Never transmit data over the network (from the server to the browser) in a clear text (always use HTTPS!),
Enforce HTTPS with HTTP Strict Transport Security (HSTS),
Never use old or weak cryptographic algorithms,
Never store sensitive data in plain text (use strong hashing like bcrypt).

4) XML External Entities (XXE) 🧨
Not that important from Angular developer perspective, but good to know when dealing with enterprise systems. It's still the no. 4 vulnerability according to OWASP Top 10.

Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations.

5) Broken Access Control 🧨
Imagine that, we allow a regular user to access the admin panel because we haven't properly secured our routes in the application on the client part (Angular) or most importantly on the server-side. Always make sure you have proper access control checks in your API to ensure authorization like:

preventing access to the parts of the system without a proper role (admin, user, auditor, super-user),
preventing access to the parts of the system without ownership of an entity (like allowing some user to view other user's account data).

6) Security Misconfiguration 🧨
Not that important from Angular developer perspective, but good to know when dealing with enterprise systems. It's still the no. 6 vulnerability according to OWASP Top 10.

When deploying a system to production there are some configuration efforts you need to remember about. Especially, what can be a security risk is:

default systems configuration (Apache, MySQL, etc),
default features enabled that you don't need (just turn them off),
default accounts with default passwords (user: admin, pass: admin 🤦‍♂️),
displaying default error pages with the exact version of server software used (attacker may look for some known vulnerabilities for a given version).

7) Cross-site scripting (XSS) ⚠️ IMPORTANT ⚠️

When the attacker manages to execute some malicious code in the context of the website in the user's browser, it's basically a GAME OVER. Then he can steal for example user's session data (like session-id and send to his own server).

How to prevent this type of attacks (in general):

Sanitize all user input removing special characters (assuming it contains evil code).

You can watch one of my videos exampling Same-origin Policy, which is the fundamental security principle of the web, that mitigates (but not eliminates) the risk of XSS here Same-origin Policy.

8) Insecure Deserialization ⚠️ IMPORTANT ⚠️

Here is a catch! Imagine you store a userAuth object (with username, id, role, etc) in the cookie or local storage. Then the attacker changes manually the content of this object and gives himself/herself a role = admin. BOOM! If the backend side does not validate the content of the userAuth object before the deserialization (meaning creating an object from the string content in the request) we have a problem.

The way to prevent such a situation is to use a hashing function over the content in the local storage or cookie. This will ensure the integrity of the object (content was not changed by the untrusted party). The server generates the hash value of the content, attaches that hash to the content and later can use the hash to verify if the content was not changed. It is possible because ONLY the server knows the secret used in the hashing process.

9) Using Components with Known Vulnerabilities ⚠️ IMPORTANT ⚠️

Very, very easy to neglect risk. We build applications with tons of npm modules. As we build our application some of our npm dependencies may turn out to be vulnerable, unsupported, or out of date and introduce security holes!

How to fix? Before every production deployment run npm audit to make sure your dependencies are secure to be used! And before making a decision of even using some npm module as your core dependency, make a proper background check of a given library/component to mitigate risks in the future.

10) Insufficient Logging & Monitoring 🧨
Here are some examples of vulnerabilities falling into this category:

your system experiences a data breach and no-one notices it (or notices after a very long time)
auditable events (logins, failed logins, and high-value transactions) are not logged
access control failures, server-side input validation failures are not logged
errors generate no, inadequate, or unclear log messages
logs are not monitored for suspicious activity

What to do in such cases?

create logs with sufficient content, context, and good format,
store logs for sufficient time to allow a delayed analysis,
and most importantly MONITOR your logs 🤓

That's it! You have just learned the most important parts of OWASP Top 10!

Role-based auth in Angular 9 🔑

Bartosz Pietrucha — Tue, 18 Feb 2020 06:48:51 +0000

👉 Join the Security Academy to master Web Security!

⚡ the case of role-based application
⚡ a domain model for a multi-account system
⚡ vectors of authorization
⚡ designing secure REST API for roles
⚡ userAuth object
⚡ Router Guards
⚡ HttpInterceptors
⚡ Silent auth (RxJS magic!)
⚡ Express.js middlewares
⚡ DEMO

Angular Enterprise Security Academy is OPEN 🤩

Bartosz Pietrucha — Thu, 06 Feb 2020 15:26:54 +0000

Do you want to learn all you need about Web Security and implement a role-based enterprise-grade authorization in Angular and Node.js?

I am happy to announce that Angular Enterprise Security Academy is open!
During the upcoming 10 weeks, we will be working together with our group to

Have a solid understanding of the Web Security model
Know Web Security vulnerabilities and prevention methods
Implement a role-based authorization system in real-life application
Know how to secure Angular application and backend API

You can join here https://angular-academy.com/security and use exclusive DEV_TO_25 discount code to get 25% off the price!

The idea is that students learn from the videos in their own time, and we meet on a weekly basis on live sessions to answer questions, review the code and overcome all challenges!

Let's meet there!

Angular Security Checklist

Bartosz Pietrucha — Thu, 23 Jan 2020 13:15:37 +0000

While developing Angular applications we need to pay strong attention to security aspects to prevent, simply speaking from being hacked!

There are many ways we may put our application users in danger and they might be victims of attacks like Cross-site scripting (XSS) or Cross-site request forgery (CSRF). Here is a list of the essential checks you have to perform to raise the level of security of your applications.

👉 Use HttpOnly and Secure cookies,
👉 Sign the cookies and tokens (like JWT) with a strong secret,
👉 Do not store sensitive data in JWT payload,
👉 Ensure your JWT library does not accept alg: none,
👉 Transport all data over HTTPS,
👉 Use Content Security Policy ver. 2,
👉 Do not allow inline scripts (no unsafe-inline),
👉 Use integrity property of all external scripts,
👉 Avoid Angular's bypassSecurityTrust*() methods,
👉 Use CSRF protection with CSRF-Token,
👉 Avoid custom auth library implementation,
👉 Check all API endpoints for role-based authorization,
👉 Use AoT compilation for template checks.

Here you can get a free printable checklist:
⚡ Angular Security Checklist PDF ⚡

Let me know in the comments if you are aware of all the checks and I will be creating more content covering these aspects!

🔴 LIVE [Role-based auth in Angular 8] 🔑

Bartosz Pietrucha — Wed, 20 Nov 2019 08:13:49 +0000

Join me LIVE on Monday, 25 Nov, 19:00 GMT to learn about:
[LINK] https://youtube.com/watch?v=p34F1qGAxBQ
👉 the architecture of role-based app
👉 possible security vunerabilities
👉 Router Guards & Interceptor
👉 some tricks with RxJS
👉 Express.js JWT middleware & more!