If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits from a domain allowed by the policy, then any malicious content running on that domain can potentially retrieve content from the application, and sometimes carry out actions within the security context of the logged in user. These are the steps I usually follow to try and find a CORS vulnerability:

1. Check if responses have the Access-Control-Allow-Credentials header set to true. It specifies that cross-origin requests can include cookies.
2. If they do, note down which one of those responses might have relevant information to be forwarded to an external domain.
3. Add an external domain to Origin and check if it gets reflected back in the Access-Control-Allow-Origin header. If it does, it means that the server accepts cross domain requests.
4. Do the same test with Origin: null to see if it gets reflected back. If it does, a request from within an iframe can be made to exploit it.
5. Try to understand which domains are whitelisted.
6. If a vulnerability from any whitelisted domain can be leveraged (XSS or Open Redirect), use it to do a request from it.
7. Test without the Origin header to see if the requests still get blocked. In 'no-cors' mode, the browser does not include the Origin header in the request and the server's response is opaque, meaning that its contents cannot be accessed by JavaScript code. This mode is intended for cases where the response from the server is not needed, such as when making a request to a third-party analytics service. It can be used to exploit CORS when requests without the Origin header are allowed.