ngx-cookie-service is a small, actively maintained Angular library for reading, writing, and deleting browser cookies, and using it securely comes down to which flags you pass, not the library itself. The ngx cookie service wraps the browser's document.cookie API in an injectable Angular service, which is convenient, but it also means you inherit every cookie footgun the browser has. This guide covers what the package does, where teams get the security wrong, and the settings that keep session data out of the wrong hands.
What ngx-cookie-service is
ngx-cookie-service is an Angular service that lets you get, set, check, and delete cookies through dependency injection instead of touching document.cookie directly. It is small, around a kilobyte of bundle, and it tracks Angular's supported release line closely, with recent versions targeting Angular 19 and above and older Angular versions no longer supported. Maintenance is healthy: it ships releases regularly and pulls in the neighborhood of several hundred thousand downloads a week. Originally created by 7leads GmbH, it is now maintained by the Studytube team.
You inject it and use it like any other service:
import { Injectable } from '@angular/core';
import { CookieService } from 'ngx-cookie-service';
@Injectable({ providedIn: 'root' })
export class PreferencesService {
constructor(private cookies: CookieService) {}
saveTheme(theme: string): void {
this.cookies.set('theme', theme, {
expires: 30,
path: '/',
secure: true,
sameSite: 'Lax',
});
}
getTheme(): string {
return this.cookies.get('theme');
}
}
Note the older ngx-cookie package is a different, separate library; if you are picking one today, ngx-cookie-service is the more current and better-supported choice.
The one thing the library cannot do for you
Here is the constraint that governs everything else: because ngx-cookie-service runs in the browser and manipulates document.cookie, it cannot set the HttpOnly flag. HttpOnly can only be applied by the server in a Set-Cookie response header, and it exists precisely to hide a cookie from JavaScript. Any cookie you create or read from client-side code is by definition reachable by client-side code, which means it is reachable by any cross-site scripting payload that runs on your page.
The practical rule that follows: never store session tokens, auth tokens, or anything else that grants access in a cookie you manage through ngx-cookie-service. Those belong in a server-set HttpOnly; Secure cookie that your Angular app never reads and never needs to. Use ngx-cookie-service for non-sensitive UI state like theme, locale, or a dismissed-banner flag.
Setting the flags that matter
For every cookie you do set client-side, apply the defense-in-depth flags. The secure flag ensures the cookie is only transmitted over HTTPS, so it never crosses the wire in cleartext where a network attacker could read it. The sameSite attribute controls whether the cookie is sent on cross-site requests, which is your primary defense against cross-site request forgery. Use Lax as a sensible default and Strict when the cookie should never ride along on any cross-origin navigation:
this.cookies.set('locale', 'en-GB', {
expires: 90,
path: '/',
secure: true,
sameSite: 'Strict',
});
Scope the path and domain as narrowly as the feature allows. A cookie scoped to /account is not sent on requests to /public, which shrinks the surface where it can leak. Broad domain=.example.com scoping shares the cookie across every subdomain, so only do it when you genuinely need to.
XSS is the real threat model
Because client-side cookies live and die by JavaScript, an XSS vulnerability anywhere on the origin can read every cookie ngx-cookie-service can read. That reframes cookie security as mostly an XSS problem. Angular helps here: its template engine escapes interpolated values by default and treats bound values as untrusted, which blocks the most common injection paths. The danger is the escape hatches. bypassSecurityTrustHtml and friends turn Angular's protection off, and [innerHTML] bindings render whatever you hand them.
Audit every use of the DomSanitizer bypass methods and every innerHTML binding, and make sure user-controlled data never reaches them unsanitized. Pair that with a Content Security Policy that forbids inline scripts, so that even a successful injection has a much harder time executing. For a deeper treatment of client-side injection, see our writeup on SQL injection testing for the server-side analogue and the Safeguard Academy for the frontend side.
Keeping the dependency healthy
ngx-cookie-service is well maintained, but a well-maintained dependency still needs attention on your side. Because it tracks Angular's supported versions, upgrading Angular and upgrading ngx-cookie-service tend to move together; pin compatible versions and update them as a pair rather than letting one drift. When you bump it, read the release notes for any change to default behavior around sameSite or path handling, since those defaults have shifted across the broader cookie ecosystem over the years. An SCA tool such as Safeguard can watch the package for newly disclosed advisories so a future issue does not sit unnoticed in your lockfile.
A short checklist
Before you ship a feature that uses ngx-cookie-service, confirm the following. No auth or session token is stored in a client-readable cookie. Every cookie you set carries secure: true. Every cookie has an explicit sameSite value. The path and domain are scoped as tightly as the feature allows. And your XSS defenses, Angular escaping plus CSP, are actually in place, because they are what stands between an attacker and every cookie this library can touch.
FAQ
Can ngx-cookie-service set HttpOnly cookies?
No. HttpOnly can only be set by the server in a Set-Cookie response header, and its whole purpose is to hide the cookie from JavaScript. Any cookie ngx-cookie-service manages is readable by client-side code, so it should never hold sensitive tokens.
Is ngx-cookie-service still maintained?
Yes. It ships releases regularly, tracks Angular's supported version line, and is maintained by the Studytube team. Recent versions target modern Angular releases, and it pulls several hundred thousand downloads a week.
What is the difference between ngx-cookie-service and ngx-cookie?
They are separate libraries with similar goals. ngx-cookie-service is the more actively maintained and current option and is generally the better choice for new Angular projects.
What flags should I always set on client-side cookies?
Set secure: true so the cookie only travels over HTTPS, and set an explicit sameSite value (Lax or Strict) to defend against CSRF. Scope path and domain as narrowly as the feature allows.