As applications become intertwined with human life and with more and more bad actors around, the need to secure your applications becomes imperative. A few of the common security threats are detailed here:

• Sensitive data leakage: Some of the data being passed over APIs and stored in databases can be incredibly sensitive (phone numbers, credit card numbers, and so on). Hackers might want to steal this data. Besides preventing such theft, there are often legal regulations on privacy to ensure that data is encrypted at rest and in transit. Companies can be liable for legal injunction if they allow theft from their platforms.
• Denial of Service: Denial of Service attacks attempt to make applications unavailable by overwhelming them with fake/spurious traffic. A particularly nasty form of such an attack is a Distributed Denial of Service (DDos) attack where the traffic is sourced from multiple sources to avoid detection of the traffic generation source.
• Cross-Site Scripting (XSS): In these attacks, malicious scripts are injected into otherwise benign and trusted websites, such as in comments on a forum. When the user clicks on these links, the scripts are executed with the user authentication information cached in the browser and this can cause malicious behaviour.
• Injection attacks: Attacks such as SQL injection, LDAP injection, and CRLF injection involve an attacker sending some sort of script inside a form and when the script runs, it causes commands to execute without proper authorization. The script could be as destructive as dropping an entire database table.
• Weak authentication: Hackers get access to sensitive applications such as banking websites because the authentication mechanisms are not hardened enough. Simple authentication mechanisms like passwords can be easily stolen/inferred.

Some of the remediation strategies include the following:

• Authenticate and authorize all API requests: Authentication is used to reliably determine the identity of an end user. Authorization refers to the process of determining what resources only the identified user has access. For APIs, the authentication mechanism is often a temporal access token, which can be obtained/refreshed via an external mechanism. This token is sent with each API request. This token can be processed at the backend and can be used to reliably infer the identity of the user. Sometimes authorization information (like roles) are encoded in the token. There are many standards for authorization tokens, and JWT (JSON Web Tokens) is a popular one. It is based on an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed, and thus tampering of the information in transit can be easily caught . JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair. https://github.com/dgrijalva/jwt-go is an Golang library for JWT usage.
• For sensitive human-consumable applications like banking websites, multi-factor authentication (MFA) reduces the risk of compromised accounts. Here, besides a standard username/password authentication, an alternative authentication mechanism (such as sending a one-time code to a registered phone number) is used. Thus, even if the password is stolen, access is not granted to the hacker.
• Privacy concerns can be mitigated via the encryption of data. HTTPS is the de facto standard for secure messages and internally uses TLS/SSL to encrypt the payload. The standard Go library net/http package has http.ListenAndServeTLS(), which allows HTTPs to serve out of the box from a Go application. However, a more popular option is to use a sidecar, with a specialized HTTPS sink-like Caddy or Ngnix, which proxies a Go application. We already looked at Nginx earler; Caddy (https://caddyserver.com/) is an HTTPS reverse proxy, written entirely in Go. It has some cool features including :
  • Modern ciphers including AES-GCM, ChaCha, and ECC by default, balancing security and compatibility.
  • Man-in-middle detection: Caddy can detect when the client's TLS connection is likely being intercepted by a proxy, giving you the ability to act accordingly. Because it's written in Go, its not affected by memory-safety attacks like Heartbleed.
  • Mutual authentication: With TLS client authorization support in Caddy, you can allow only certain clients to connect to your service. PCI-compliant code.
  • Key rotation: Caddy rotates TLS session ticket keys by default, thus helping preserve forward secrecy, as in visitor privacy.
    That said, at the time of writing, Nginx is still faster than Caddy. To see the performance comparison between the two, you can visit https://ferdinand-muetsch.de/caddy-a-modern-web-server-vs-nginx.html.

• Quotas and throttling: If a typical API has a profile of about two requests per second (RPS) per user, then a load of 10 RPS from a user can be deemed to be suspicious. Quotas can be used to ensure that specific users have a set limit, in terms of the number of requests per second for each API. Throttling also protects APIs from DOS attacks. Caddy has the http.ratelimit construct to rate-limit requests from a particular IP address. NginX has a more feature-rich rate limiter, allowing for the rate limiting of specific geos, headers, and so on (described in detail at https://www.nginx.com/blog/rate-limiting-nginx/) . The NginX implementation uses the leaky bucket algorithm for rate limiting, where the leaky buckets represents a first‑in, first‑out (FIFO) scheduling algorithm.
• Using security headers: The HTTP headers have a variety of security-related headers. For example, the Allowed Hosts header provides a list of fully qualified domain names (FQDN) that are allowed to serve your site. This prevents attacks such as DNS cache poisoning .

This section was meant to provide a high level overview of different things to consider in securing applications. Security is a big area to cover and a detailed treatment is out of the scope of this book.