Skip to content

API Security

Jump to bottom
FullstackCodingGuy edited this page Feb 13, 2025 · 12 revisions

General Security Issues

REST API Security

  • REST api should be stateless (api should not rely on any cookies for login)
  • Requests should require Authentication (for each and every api request)

image

XSS - Cross Site Scripting or type-0 XSS

DOM Based XSS (or as it is called in some texts, "type-0 XSS") is an XSS attack wherein the attack payload is executed as a result of modifying the DOM "environment" in the victim’s browser used by the original client-side script, so that the code runs in an "unexpected" manner. In the application the HomeComponent uses the innerHTML property to write the URL hash fragment on the HTML document. This method does not sanitize the value before adding it to the document leaving the application vulnerable to scripts.

Best Practices

  • Do not use innerHTML on any view, remove if used - alternatively use the html to render the values as it considers the values as unsafe and angular sanitizes the values

Identify Vulnerable Components, Packages, Script imports

  • Verify package versions for vulnerabilities
  • Check the script imports and its version for vulnerabilityies in synk.io

Avoid using eval

  • Check your code uses eval anywhere, it may give you freedom of running the scripts but remove it without mercy, it is a culprit.
  • Find out alternative way to run the code either statically or dynamically (some of dynamic libraries allow you to run code dynamically module federation, singlespa etc,.)

Command injection occurs when an attacker is able to execute arbitrary commands on the host operating system via a vulnerable application. In this case, the application does not validate user input and evaluates it. So instead of a number, user can pass commands, which will be executed on the server. E.g process.exit(0) will shut down the server.

Standard Security Practices

image

General

  • Use HTTPS

  • Use OAuth2

  • Use WebAuthn

  • Use Leveled API Keys

  • Authorization

  • Rate Limiting

  • API Versioning

  • Whitelisting

  • Check OWASP API Security Risks

  • Use API Gateway

  • Error Handling

  • Input Validation

  • Cross Site Scripting (XSS), Clickjacking , Content Security Policies (CSP)

  • Prevent Denial of Service (DOS),

  • Configure Cross Origin Resource Sharing (CORS) Policy ( CORS will keep your application safe from malicious attacks from unknown sources )

  • Prevent SQL Injection, Use ORM tools, Sanitize input data, Use hashing for sensitive information

  • Limit the request size (body)

  • Hide server side errors from the user, use logs aggregate and monitoring tools

  • Load the secrets securely, vault based environment variables

  • Use compression for data

HTTPS

Screenshot 2024-12-16 at 4 21 52 PM

Security Solutions

image

  • Session - The server stores your identity and gives the browser a session ID cookie. This allows the server to track login state. But cookies don't work well across devices.

  • Token - Your identity is encoded into a token sent to the browser. The browser sends this token on future requests for authentication. No server session storage is required. But tokens need encryption/decryption.

  • JWT - JSON Web Tokens standardize identity tokens using digital signatures for trust. The signature is contained in the token so no server session is needed.

  • SSO - Single Sign On uses a central authentication service. This allows a single login to work across multiple sites. `Basically, Single Sign-On (SSO) is an authentication scheme. It allows a user to log in to different systems using a single ID.

The diagram below illustrates how SSO works. image

Step 1: A user visits Gmail, or any email service. Gmail finds the user is not logged in and so redirects them to the SSO authentication server, which also finds the user is not logged in. As a result, the user is redirected to the SSO login page, where they enter their login credentials.

Steps 2-3: The SSO authentication server validates the credentials, creates the global session for the user, and creates a token.

Steps 4-7: Gmail validates the token in the SSO authentication server. The authentication server registers the Gmail system, and returns “valid.” Gmail returns the protected resource to the user.

Step 8: From Gmail, the user navigates to another Google-owned website, for example, YouTube.

Steps 9-10: YouTube finds the user is not logged in, and then requests authentication. The SSO authentication server finds the user is already logged in and returns the token.

Step 11-14: YouTube validates the token in the SSO authentication server. The authentication server registers the YouTube system, and returns “valid.” YouTube returns the protected resource to the user.

The process is complete and the user gets back access to their account.`

  • OAuth2 - Allows limited access to your data on one site by another site, without giving away passwords.

References

Clone this wiki locally