Develop Reference

How to prevent sending custom value to CORS disabled API?

I get a photo(image file) from my user. I can access to their camera and they will take a photo and send that photo for me. Codes are written in JavaScript.
In my API, CORS is disabled and only requests from my site are valid.
I want to be sure that photo which i will get it, is a photo that is taken via camera(codes are written in JS).
I want to get a image from API endpoint. That value is get from user camera and will be send via ajax request.
Can user send custom value to API if CORS is disabled?
I know that client side user can access JS codes via browser inspector, but can user change JS codes and send custom value to CORS disabled API?

A user can send whatever they want to your HTTP endpoint.
HTTP endpoints are public. You have no control over what is sent to them.
A user could manually construct an HTTP request (e.g. with a tool like Postman or any programming language) and send whatever data they like without involving a browser at all.

Any client (it doesn't even need to be a browser) can send arbitrary values to your API. It does not need to be a photo taken from the camera, it does not even need to be a photo at all. And you cannot prevent that, or force a browser to do anything. That includes preventing savy users from messing with your JS code.
CORS is a client-side security measure implemented in many clients that prevents js code on other domains from accessing your API with the user's credentials. It does not help you here.

Javascript: How can I force a POST request to treat the user as not authenticated

I'm using Javascript and XmlHttpRequest to POST to another URL on the same site. Users must be authenticated to access the page where the Javascript runs, but I need to submit the POST to the second URL as a non-authenticated user (to prevent the server from running code which is always run for authenticated users). Is there any way to submit the POST so that it appears to come from a non-authenticated user (so the server doesn't pull the user's authentication information from their session and treat them as authenticated for the POST)?
For example, is there a way to open a new session just for the POST, or to change the session ID just for the POST?
Note:
I tried to explicitly perform authorization using credentials for a non-existent user, but that didn't make any difference.
If this can be done using ajax instead of XmlHttpRequest, that's an acceptable solution.

Unfortunately this can not be achieved only in JavaScript, so you will have to make some changes on your server. You have two options:
Either you mark your session cookie as HttpOnly, so it won't be sent together with your request. But this will mean, that all your requests are sent as unauthenticated user.
Second option is use of a subdomain for this endpoint. Cookies are sent with XmlHttpRequests only on the same domain to prevent cross-site scripting. So if you move the server endpoint from www.example.com/myresource to api.example.com/myresource, the cookie will not be sent.

OAuth2 Implicit Grant with Ajax

I'm implementing OAuth's implicit grant type in a Javascript application using Angular. I would like to request a token using an AJAX request. When I make the request to my OAuth server, it responds with a 302 and a location header. As per the spec, the location is my configured redirect URL with a hash fragment containing the access token.
My problem is I have no way to read the hash fragments if it is an ajax request, since XmlHttpRequest automatically follows the location header. I can't seem to get any information about the initial response (the one whose status is 302, and has the location header.) If there were some way to intercept that response and read out the location header, I would be set.
I would like requesting a token to happen behind the scenes, without the user knowing it is even happening. (That is, without the browser's URL jumping all around.) I should also mention that I am working within an environment where SSO is available, and the user will most likely have already authenticated via SSO. As long as my OAuth server detects an SSO cookie, it will know the user has been previously authenticated and to just issue a token for this application, without needing to redirect to a login page.
Is there any way to read either the location header of the first response, or to read the URL that is redirected to? It seems that xhr itself goes to great lengths to prevent this, so I'm also wondering what is the reason for that?

oauth Implicit Grant usually opens the service login window so the user can accept the service integrator then provide their login credentials. Using JavaScript you can read the hash by implementing code similar to:
var browserRef = window.open(add your URL here, '_blank','location=yes,clearsessioncache=yes,clearcache=yes');
browserRef.addEventListener ('loadstart', function(event) { add code to read the hash)}

How can an API call be handled completely on the server side without the client seeing it?

I would like to know if the following is possible and if it is please guide me in the right path.
My site is x.com and when a user submits a form on my site an API call is made to y.com which returns a JS hash (yeah very outdated, I know).
You can see the call to y.com being made in FireBug with returned params. Problem is that Adblocker Plus is intercepting this content and blocking it from view. (Not good (displaying a message about ad blocker is not a solution (In this case the user is actually expecting the ad)))
Is it possible to have my server make the request to y.com server (without the user's client being aware) get the response on my server side, and then finally generate the page and with the response content in the body, and lastly render to client?

This is entirely possible. You could define an endpoint on your local rails app (x.com) and submit the form to that endpoint. Then use an HTTP library, I prefer rest-client, to then submit the form to y.com.

how to make a cross domain request that isnt forgeable

I need to get some data from Site B into Site A's server side. In order to make the request to Site B to retrieve the data, there are cookies associated with Site B's domain which need to be present. I assume I therefore need to do this in javascript with JSONP?
My ideas was to use JavaScript to make the request to B and then capture the result and stick it a cookie on As domain such that subsequent requests to A would carry the cookie with the returned data (it doesnt matter that it takes two requests to A to get the information to A's serverside). This would work fine, except its completely hackable.
The data itself isn't secret but I need to prevent request forgery or people on Site A calling the JSONP callback function manually, or setting the A cookie manually with stolen or otherwise faked data. Also, is there any other loophole for hacking? This would also need preventing!
The only way I can think of doing this is:
Site A generates a random token and stores it in the session. It then appends this token to the querystring of the JSONP request to Site B. Site B then responds but encrypts the usual data along with the token using digital signing. Site A then sticks this value in a cookie on A. In the next request to A, As server side can capture the cookie, get the value, decrypt it, check the token and if it matches the value in the session, trust the rest of the data.
Does this sound sensible? Is there an easier way? My goal is to reduce the complexity at As end.
Thanks

The way to avoid it being hackable is to have the sites communicate with each other directly, rather than using client-side JavaScript. Write a small light-weight REST API which allows the data to be transferred behind the scenes, server to server.
When linking to Site A, include an authentication token in the URL which can then be checked using the behind-the-scenes call to Site B. This call can transfer any additional required information. The token should probably be IP-bound, and expire after use. Upon success, you can set up your cookie information in Site A, to avoid the need for further round trips.

You could use easyXDM to communicate between the domains. With it you have two javascript Programs, one on the consumers domain, and one on the providers, which can assert the domain of the consumer. Both these Programs can interact with the user, and the user can authenticate itself to both parties. With the providers Program knowing who the user is, and knowing who the consumer is, the provider can pass whatever data it wants to the consumer.
This is what big companies like Twitter, Disqus and LinkedIn use for their API's.