How can I ensure my Static Web App + SQL Database/Server isn't Phishing?

Robert Bogan 20 Reputation points

I'm a new developer without a CS background, and I'm new to both Azure and hosting web apps. I apologize in advance for my own verbosity in giving details here - and for my own ignorance about what are likely basic tenets in securing both my user data and my database.

In all, my web app used:
An F1 App Service plan
An App Service (.NET + EF, using CI/CD with a private Github repo)
A Static Web App (React, CI/CD with Github again)
An SQL Server
An SQL Database (Basic plan)

Anyway, after my delight at finally hosting my first (highly ambitious) web app on Azure, it was mere hours before Google Chrome flagged my site as being a risk of phishing. The message was as follows:

"Dangerous site

Attackers on the site you're trying to visit might trick you into installing software or revealing things like your password, phone or credit card number. Chrome strongly recommends going back to safety."

My kneejerk reaction was to immediately delete the Static Web App I had deployed, although I imagine my panicked reaction was a wasteful and incorrect one! I'm glad it occurred a few hours, rather than a few months, after deployment - and before any future employer views it (it's a real portfolio app)!

Although I'm embarrassed at having been flagged (and I can see some red flags having written in more detail about it below), I'm posting this question so any future learners can benefit from any advice given. I'd welcome any advice on the correct way to remedy the issue Google has flagged, and to ensure the next deployment of my site is secure for users.

The web app is essentially a cross between Anki and a quiz application. In the app, users will click on answers - although a lot of detailed information related to each question is pulled from the database for users to see.

There are five POST requests that can be made by the user to the database. Two of them are registration-related. Indeed, the only typed information a user can enter is an email and password in the Sign Up and Log In components. Two of the other three POST requests are to indicate whether a question in the app was answered correctly (and updates both the 'Next Review Time', 'Correctly Answered', and 'Number Of Attempts'.) The final POST request simply resets the 'Correctly Answered' and 'Number Of Attempts' in one model in the database.

I feel this is significant too: I can connect to the SQL Server from my local SQL Server Management Studio. I was using this to check whether I could add myself as a new user. (And to make sure the databases in the app are populated correctly). Essentially, I think the phishing might be linked to my being to view a user email! If a user were to sign up, then in my local SQL Server Management Studio, I can view the following information:
User Email, the PasswordHash, and PasswordSalt
I imagine the email being visible to me is the cause of the phishing/dangerous warning as flagged by Google, although I'm really not sure.

In any case, I'll finally ask the question:

  1. What steps should I need to take to ensure my future deployment is completely free of phishing?
    In addition, will I need to change or remove the 5 existing 'test' users that exist in my database? (Indeed, will I need to completely replace the SQL database with a new one?)

Thanks in advance for any help.

Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
6,764 questions
0 comments No comments
{count} votes

Accepted answer
  1. SnehaAgrawal-MSFT 18,191 Reputation points

    @Robert Bogan Thanks for reaching here! How to further protect your App Service app from threats-

    1. Secure your apps with HTTPS-
    2. To secure your app against all unencrypted (HTTP) connections, App Service provides one-click configuration to enforce HTTPS.
    3. By default, your App Service app accepts requests from all IP addresses from the internet, but you can limit that access to a small subset of IP addresses
    4. Azure App Service provides turn-key authentication and authorization of users or client apps
    5. When authenticating against a back-end service, App Service provides two different mechanisms depending on your need: Service identity, On-behalf-of (OBO**)**
    6. Connectivity to remote resources
    7. When your app connects to Azure resources, such as SQL Database and Azure Storage, the connection stays within Azure and doesn't cross any network boundaries. However, the connection goes through the shared networking in Azure, so always make sure that your connection is encrypted.
    8. For web workloads, we highly recommend utilizing Azure DDoS protection and a web application firewall to safeguard against emerging DDoS attacks.

    For details- suggest you to refer this detail document link-

    Hope this helps, Let us know.

    1 person found this answer helpful.
    0 comments No comments

1 additional answer

Sort by: Most helpful
  1. hossein jalilian 1,265 Reputation points

    Thanks for posting your question in the Microsoft Q&A forum.

    To mitigate the phishing risk and guarantee secure future deployments:

    1. Implement proper authentication and authorization mechanisms to protect user credentials.
    2. Encrypt sensitive data such as passwords to prevent unauthorized access.
    3. Use HTTPS to encrypt data transmitted between the client and server, ensuring data integrity.

    Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful

    0 comments No comments