0

I have below code for appsettings.json and startup.cs. The code runs fine. but it doesnt block the requests coming from postman.

    //appsettings.json:

    {
    "AllowedOrigins": "http://mydomain1;http://mydomain2"
    }

    //startup.cs

    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ApplicationDbContext dbContext, IOptions<AppSettings> appSettings)

    if (!String.IsNullOrEmpty(_appSettings.AllowedOrigins))
    {
              var origins = _appSettings.AllowedOrigins.Split(";");
              app.UseCors(x => x
                        .WithOrigins(origins)
                        .AllowAnyMethod()
                        .AllowCredentials()
                        .AllowAnyHeader());
    }

The intenion of the above code is no other domains except what is in AllowedOrigins should be allowed to make api calls from front end. But i see postman is allowing it. Is there anything else i need to take care of so that postman or anyother hackers trying to make api calls can be blocked

Full Stack Brain
  • 455
  • 1
  • 6
  • 19
  • 1
    [Postman isn't a browser](https://stackoverflow.com/questions/43432743/will-cors-policy-prevent-resource-access-from-non-browser-requests). You need to employ some kind of authentication/authorization like certificates or api keys, etc. Don't count on browser behavior for overall security. – Crowcoder Feb 16 '21 at 14:02
  • Cors puts a header on and the Browser rejects the request not the server. Your post man is probably configured to ignore the header. If you want to block a request coming in then block it on the server. – johnny 5 Feb 16 '21 at 14:29
  • 1
    @johnny5 Postman flat out doesn't do CORS/doesn't behave like a CORS-respecting browser does – Caius Jard Feb 16 '21 at 14:35
  • @CaiusJard Oops you're correct, I was thinking about HTTPS verification – johnny 5 Feb 16 '21 at 14:50
  • So it's the browser which does that check of verifying Cors headers and rejects requests based on that – Full Stack Brain Feb 16 '21 at 19:36

1 Answers1

1

Allowed-* headers, generally referred to as CORS, are not really intended for securing an API against all unauthorized use; they're a way to limit widespread use of your API by regular, decent, middle-of-the-road browser using folk

When making a request to a back end site that is NOT the site that served up a javascript app, the browser will first contact the back end and say "i'm shortly going to issue a request to you that is being made by an app downloaded from X, what locations do you permit requests from?" and your back end tells it some list

The browser then goes "does it match? does the back end allow use from apps originating from X?" and if it doesn't then the browser cancels the app's request

You must therefore appreciate that this is purely an elective behavior built into standard browsers - if the user uses a browser that doesn't behave in this way, your back end will be in receipt of requests that are not checked. CORS works because most people run standard browsers that behave well. There's no point someone out there ripping off your javascript app, branding it as theirs and putting it up on their site, but making it bash away at your back end to do all the funky stuff it does for free because it won't work if your back end doesn't authorize the site they uploaded it to; as soon as they try and sell use of the app to a regular joe in the street, who uses a normal browser that obeys CORS, it'll fall apart..

..but it absolutely isn't security against unauthorized use of your app in the way a proper authentication and authorization mechanism is. You're trying to stop the wrong group of people if you hope that it is; the hackers will carry on stealing use of your API while the CORS only provides actual benefits for the decent folk who use your site in a browser like you want them to (you get the benefit that they don't use some dodgy version of your app; they get the benefit that dodgy versions of your app probably don't work for them)

If you want to lock your back end down, then you're going to need something more secure and dedicated; at the very least your front end makes a secure connection to the back end, the user passes something that says who they are and hence defines what they can do (username and password) and that becomes a token or something that identifies them and permits successive interaction over a secure channel. It's secure because the traffic cannot be snooped by interim servers, the credentials or tokens that ID the user are never known to anyone other than the two end parties and you remain in control of the entire interaction. It doesn't matter if someone writes a custom client or a hacked version of the app (well.. unless they use it to trick people into thinking it's the real one, and then the people unwittingly give up their credentials) because it still relies on things (username/password/token) that are not stored in the public domain to initiate and maintain the interaction

Caius Jard
  • 72,509
  • 5
  • 49
  • 80