A couple things: Movie appears to be missing a PK. When using identity (auto-generated) keys EF needs to be told about them as well. It can deduce some by naming convention, but I recommend being explicit to avoid surprises. Your entities will need to be set up for the appropriate relationships: I.e.

public class Movie
{
    [Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public int movie_id { get; set; }  
    // ...
}

public class Rental
{
    [Key, Column(Order=0)]
    public int movie_id { get; set; }
    [Key, Column(Order=1)]
    public int user_id { get; set; }
    // ...
}

Unfortunately this doesn’t really tell EF that there is a relationship between Movie and Rental. (Or User and Rental) From an application point of view, without that relationship, what guarantee is there that the Movie_id your call receives from a client exists? It’s also a bit strange that this method is listed as an “OnGet” type method which implies a GET action rather than a POST or PUT action.

Typically with EF you will want to leverage navigation properties for you domain rather than just exposing FKs. Also, you are defining this as an async method without awaiting any async operations.

I would recommend avoiding composite keys unless truly necessary, so give Rental a Rental ID and just rely on many to one relationships for the Movie and User references:

public class Rental
{
    [Key, DatabaseGenerate(DatabaseGeneratedOption.Identity)]
    public int rental_id { get; set; }
    // ....

    public int movie_id { get; set; }       
    [ForeignKey("movie_id")]
    public virtual Movie Movie { get; set; }
    public int user_id { get; set; }       
    [ForeignKey("user_id")]
    public virtual User User { get; set; }
}

public void RentMovie(int movie_id, string email)
{
    var movie = _context.Movies.Single(x => x.Movie_Id == movie_id);
    // Better would be to go to the Session for the current logged in user rather than trusting what is coming from the client...
    var user = _context.Users.Single(x => x.Email = email);

    try 
    {        
        Rental newRental = new Rental
        {
            Movie = movie;
            User = user;
        };
        _context.Rental.Add(newRental);
        _context.SaveChanges();
    }
    catch
    { // TODO: Handle what to do if a movie could not be rented.
    }
}

In the above example we attempt to load the requested movie and user. If these do not exist, this would fall through to the global exception handler which should be set up to end the current login session and log the exception. (I.e. any tampering or invalid state should be captured and log the user out.) Where when attempting to record the rental, the exception handling can be set up to display a message to the user etc. rather than a hard failure.

You can go a step further and remove the FK properties from the entities and use Shadow Properties (EF Core) or .Map(x => x.MapKey()) (EF6) to set up the relationship. This avoids having two sources of truth for viewing/updating relationships between entities.

Optionally the Movie object could have an ICollection<Rental> where Rentals could have a RentedDate and ReturnedDate for instance so that movies could be inspected to see if a copy was available to rent. I.e. searching by name then determining if one or more copies is currently in-stock. A Rental record could be added to movie.Rentals rather than treating Rentals as a top-level entity.

Using navigation properties is a powerful feature of EF and can accommodate some impressive querying and data retrieval options via Linq without reading a lot of records and piecing things together client side.