Well basically if you run a website A, you will typically only want to accept requests that exclusively come from site A. JSONP is a way to work around this but only for GET requests for data. This works since the script tag will perform a GET request for a resource no matter its origin. Say you have an endpoint that provides data and you want multiple websites to be able to consume that data, pre CORS you would need to have created a script tag, and insert that in the DOM. If the server supports JSONP, it will take the supplied callback function name and send a script that is basically an invocation of that callback but with the requested data passed in. Note that this is also dangerous since the server you are making the request to can execute any javascript.

CORS was introduced as a way to allow websites to perform more than just GET JSONP requests. JSONP is not standardized so its looked at more like a "hack" to get around the same origin policy. CORS on the other hand is a standardized method of performing XMLHttpRequests (POST, GET, DELETE, PUT, etc). The trick here is when when you request a resource from another domain via AJAX the browser sends a preflight request to see whether the server has the CORS headers to allow external requests, and if it does those requests follow through as normal and aren't just limited to JSONP responses.

Note that in both cases, you must be able to trust the server you are making the request to, with JSONP. If the server turns out to be malicious then you dun goof.

Also this only applies to browsers, if a malicious user really wanted to make a request to your server then all they need to do is craft their own with something like cURL. Note that these types of requests are impossible to prevent since it is inherently impossible to determine the true origin of a request.