Some of the software engineers I have met (not a lot, I hope) casually add CORS in the API because it wasn't working when their frontend tries to call it. They google around the error and just add CORS with wildcard value '*', allowing all domains to now able to access the API from the browser.

Once it works, CORS settings is left forgotten and people move on.

Here, we take a moment to appreciates CORS a little bit more.

Allowing all domain to be able to call your API is dangerous. What CORS does is allow you to configure only the websites with specific domains can call your API. By doing so, it prevents a few things:

First, it prevents the API from being able to access by any random website.

Imagine the scenaio where wildcard '*' is used for CORS setting. Alice has an API which is only meant for Alice's website, Bob creates another website that consumes Alice's API which has some expensive operations. Now, Bob can abuse Alice's API, the browsers from Bob's users will then be executing API calls to Alice's API server, taking up resources - one variant of DDoS attack.

Second, it prevents something more subtle - malicious hackers trying to steal users' credential information. Here is how it works.

Imagine; Alice's API sets some cookies on the browser, Bob's Web UI now executes GET call to Alice's API by setting 'withCredentials' value to true.

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://alice-api.com/', true);
xhr.withCredentials = true;
xhr.send(null);

Now this request will sent back the cookies previously set by alice-api on the user's browser. The cookies can contain user's credential information used to authenticate to alice-api.

On the server side, there is something called Access-Control-Allow-Credentials header,  of which the value can be either true or the header is ommited.  It goes hand-in-hand with CORS Access-Control-Allow-Origin header.

Almost all the CORS library support setting Access-Control-Allow-Credentials header value which is either true or false (which means the header is not included in the response at all). If the header value is set to true, it allows JavaScript of whatever web application making API call can see the response. Otherwise, the app (JavaScript) can't see the response value. This is important because anything that requires user's credential is considered important and equally sensitive as user's credentials.

Scenario 1: Intended Website to API

This is the example response when Access-Control-Allow-Credentials value is set to true, and Access-Control-Allow-Origin value is set to intended website domain.

In this case, Origin is properly set to the website's domain. Everything works fine. Cookies are carried over and sent back to the API, which in turn also sends back the response, which JavaScript can access.

Now another example where Access-Control-Allow-Credentials is not included and Access-Control-Allow-Origin value is set to the intended website domain.

Now JavaScript cannot see the response and fails with the reason "CORS missing allow credentials" although the cookies are being sent to the API server, too.

Scenario 2: Malicious Website to API

This is the example response when Access-Control-Allow-Credentials value is set to true, and Access-Control-Allow-Origin value is set to intended domain.

It fails with "CORS Allow Origin Not Matching Origin" error.

Take note that cookies which belong to Alice's Website, set by Alice's API, are still being sent over in the request as shown in the screenshot below.

There you have it. Bob's website simply tries to execute GET API from Alice API. It sends legitimate cookies from Alice's website set by Alice's API back to the API and tries to get hold of the sensitive information from the response.
But, thanks to CORS,  "Allow Origin Not Matching Origin" error prevents user from Bob's malicious website faking and stealing sensitive information, or even doing some destructive action.

Another thing that makes CORS more secure is we can't set Access-Control-Allow-Origin to '*' wildcard when Access-Control-Allow-Credentials value is set to true (quote below), so that malicious websites can't steal user's protected data just because some engineer accidentally sets '*' as  Access-Control-Allow-Origin value.

Note: When responding to a credentialed requests request, the server must specify an origin in the value of the Access-Control-Allow-Origin header, instead of specifying the "*" wildcard.

Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

I hope this helps understand CORS a little bit more.

PS: CORS is only for browser. It doesn't do anything if you are using curl command or any other manual tools.

There is an article from AWS explaining how to achieve this using Kubernetes Service. But Services on EKS create Classic Load Balancer instead of Application Load Balancer which is created if you use Ingress.

Note: Application Load Balancer is more flexible than Classic one but this is not the subject of this article.

For those who just want to see the code, GitHub repository is here.

Prerequisites

To do this, please make sure you have all other things setup such as having a domain set up on Route53 and a certificate requested from ACM. And make sure you have already had AWS Load Balancer controller set up in your EKS cluster.

You can check if you have already set up AWS Load Balancer by running the command:

kubectl get deployment -n kube-system aws-load-balancer-controller

If you don't it set up, then follow this guide to create AWS Load Balancer Controller.

Process

Once all the prerequisites are in place, create a file called deployment.yaml with the content below:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: echo-pod
  template:
    metadata:
      labels:
        app: echo-pod
    spec:
      containers:
      - name: echoheaders
        image: k8s.gcr.io/echoserver:1.10
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080

Then, run

kubectl apply -f deployment.yaml

Now, the pods should be up and running

kubectl get pods -l app=echo-pod

Next, create a service with a file called service.yaml. Note that we are using NodePort instead of LoadBalancer type.

apiVersion: v1
kind: Service
metadata:
  labels:
    app: echo-pod
    app.kubernetes.io/name: echo-pod
  name: echo-pod
spec:
  ports:
  - name: http
    nodePort: 30162
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: echo-pod
  type: NodePort

NodePort is being used here but ClusterIP can also be used.

Now, the service should be created.

kubectl get service -l app=echo-pod

Next, create ingress file. Take note the certificate-arn annotation, where you have to use your certificate ARN from ACM. Host name must be updated to your host name, too.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx:certificate/xxxxxxx
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
  labels:
    app: echo-pod
    app.kubernetes.io/name: echo-pod
  name: echo-pod-ingress
spec:
  ingressClassName: my-alb-ing-class # or whatever ingress class name of ELB
  rules:
  - host: nayyaung.com # change it to your host name here
    http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: ssl-redirect
            port:
              name: use-annotation
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: echo-pod
            port:
              name: http        
  tls:
  - hosts:
    - nayyaung.com # change it to your host name here

Finally, you will see ALB being created. Wait for it to reach Active stage then go over to Route53 console to create host record using your host name and map it to the ALB just being created.

One interesting things to notice:

"listen-ports" annotation has both p0rt 80 and 443. And the actions.ssl-redirect annotation is set up to redirect http traffic to https using ssl-redirect action. ssl-redirect action must be the first rule so that ALB will evaluate it first, details in here.

So, if the user uses port 80, ALB will reroute it to port 443, with given SSL certificate on that port, and terminate it before routing it via the ingress rule to echo-pod which is using only port 80 (without SSL).

Again, the code is available on my GitHub repository.

Thanks for reading.

XSS = Cross-Site Scripting ,  CSRF = Cross-Site Request Forgery

XSS

It is a script injected inside the web application of the (innocent) host by

• Inserting script into the inputs of the website such as comment box, which will then be executed when users use the website.
• Placing it in the URL of the query string of actual host and letting the user click the link.

XSS is executed inside the host domain so that it is more affective and can bypass a lot of browser's prevention. It can read all the information from the local storage or cookies written by the targeted host and can send this information over to malicious website for further actions.

The protection is to sanitize all the user inputs and to encode and escape all the character so that the injected code doesn't execute when it gets rendered on the browser. Full explanation can be found on the OWASP website.

CSRF

As the name implies, this is meant to trick user into doing some unintended action. This is done by simulating legitimate action performed by the URL but with a different parameters and send it to unaware users pretending to be an innocent link.

https://www.some-legitimate-bank.com?action=transfer_money_to_hacker_account&value=1000

If the user clicks the link crafted and given by malicious hacker while his browser session on the targeted website is still alive, it will end up performing the action intended by the malicious hacker.

CSRF can be prevented by one-time challenge called CSRF token and most of the reputable modern web frameworks has it built-in. Full explanation on how to protect it is explained also on OWASP website

It happened to me few months ago. When the PC boots, graphic doesn't get detected and only built-in graphic port from the motherboard works.

Several method such as re-seating, cleaning dust from the PCI slot and the card have been tried in vain. The only solution that works is to clean both the PCI slot and the card's contacts with copious amount of Contact Cleaner made by any good brand (like this one from amazon https://amzn.to/3nUMS1K ) and let it dry before putting the card back in.

Good Luck!

_{Disclaimer: Amazon referral code included}

If you use AWS ECS to deploy a container that uses openStdin, such as Console.Read() in C#, to keep the application alive, make sure "interactive" parameter in the ECS task definition is set to "true".

Otherwise, your container in ECS will keep on exiting itself consistently with Exit Code 0 (zero).
It behaves differently if you run it on docker engine, i.e. not specifying "interactive" flag will still keep the container running. But ECS will take it down if "interactive" is not set to true when you are using stdin as a mean to keep the application alive.

The other option is to let the main thread sleep infinitely if you don't want to use stdin.

If you are a software engineer and you have passed the stage of writing advanced Spaghetti code using big ball of mud design pattern, you reach a stage where you want to write the perfect code with proper design structure, using all fancy design patterns and abstraction.

But does it stop there? For some people and some organization, yes. Not sure it is for the best. Using advanced patterns with heavy abstraction everywhere usually comes with a cost, especially when it is not necessary.

At the end of the day, it is not only about how beautiful your code is. It is also about being easy to read and maintainable by someone else. Complex code takes longer to modify by someone else who is not the original developer. It adds the higher chance of your successor rewriting your code (breaking DRY) for the sake of simplicity for him/her. There is a balance to strike. If you don't know the balance, be err in favour of simplicity. More often than not, being (reasonably) simple is better than being perfect.

Fancy Vocabulary

Brilliant Jerk : a software engineer who is relatively knowledgeable and smart but refuses to see more than technical aspects.

This is someone who has strong technical skills but not willing to acknowledge that there is human aspects in the project. That person will fight with everyone to get the most aesthetically pleasing (to him/her) code.

Organizations may or may not want that kind of people as an employee but, as a rule of thumb, don't be that person. Better to stay as a team player, unless you are Maverick from the movie Top Gun.

This is the personal website of Nay Yaung.
He is a software engineer originally from Myanmar and this website here expresses his own personal views.

Go to contact page for more information.